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SUMMARY 


The  IPCS  program  has  proven  that  considerably  higher  levels  of  flight  system  performance 
can  be  obtained  by  using  a highly  integrated  propulsion  system  control.  The  techniques 
employed  to  achieve  this  improved  performance  go  far  beyond  the  use  of  such  advancing 
technology  as  digital  electronics  or  control  mode  analysis.  They  include  (1)  early 
planning  for  integration,  (2)  early  involvement  of  all  concerned  parties,  and  (3)  freer 
communication  between  all  concerned  parties,  down  to  the  working  engineer  level,  than 
is  considered  common  in  weapons  system  programs.  Proper  use  and  management  of  these 
three  items  constitutes  the  IPCS  methodology.  The  goal  of  the  Methodology  document  is 
to  provide  assistance  in  establishing  the  philosophy  and  direction  that  will  minimize 
program  risk  and  cost. 

Planning  is  the  first  task  that  must  be  addressed  jointly  by  program  participants.  A 
time  line  showing  a sequence  of  64  key  events  is  provided  as  a guide.  Division  of 
responsibilities  should  be  negotiated  within  contractual  constraints  and  documented  in 
proposals  to  the  customer.  This  division  should  reflect  the  resources  that  each 
organization  can  bring  to  bear.  In  many  cases  the  resources  are  owned  by  the  government; 
availability  and  possible  use  of  these  facilities  should  be  explored  in  depth. 

One  contractor  must  have  responsibility  for  making  overall  system  studies  and  decisions. 

If  the  customer  elects  to  retain  this  responsibility,  he  should  be  prepared  for  substantial 
involvement  with  the  contractors  in  all  aspects  of  their  work;  technical,  contractual, 
and  financial . 

The  development  of  requirements  is  a term  applied  to  those  activities  that  lead  to  a 
detailed  set  of  preliminary  hardware  component  and  subsystem  requirements  and  software 
requirements.  These  activities  include  much  of  the  preliminary  design  and  many  system 
trade  studies.  Check  lists  and  time-phased  decisions  are  identified  to  the  intercompany 
design  team.  The  development  of  requirements  is  an  iterative  process  that  benefits  from 
the  free  exchange  of  information. 

A compendium  of  engineering  practice  that  was  successfully  applied  in  the  IPCS  program 
is  provided  in  the  areas  of  hardware  and  software  development  and  system  integration 
and  test.  Recommendations  in  these  areas  reflect  the  IPCS  philosophy  of  early  planning, 
involvement  of  all  parties,  and  free  communication. 


1.0 


INTRODUCTION 


The  IPCS  program  has  proven  that  considerably  higher  levels  of  flight  system  performance  can  be 
obtained  by  utilizing  a highly  integrated  propulsion  system  control. 

The  techniques  employed  to  achieve  this  improved  performance  go  far  beyond  the  use  of  such 
advancing  technology  as  digital  electronics  or  control  mode  analysis.  They  include:  1)  Early 
planning  for  integration;  2)  Early  involvement  of  all  concerned  parties;  3)  Freer  communication 
between  all  concerned  parties  than  is  considered  common  in  weapons  system  programs. 

Proper  use  and  management  of  these  three  items  constitutes  the  IPCS  methodology. 

1.1  PURPOSE  AND  SCOPE  OF  METHODOLOGY  DOCUMENT 

The  historical  trend  of  aircraft  controls  development  has  been  toward  greater  functional 
integration  to  maximize  aircraft  mission  capability.  This  trend  is  expected  to  continue  as 
analytical  techniques  are  refined  and  flightworthy  digital  electronic  hardware  becomes  more 
readily  available. 

The  planning,  organization,  and  control  of  the  program  to  develop  an  integrated  control  system, 
which  requires  the  crossing  of  both  corporate  and  technical  boundaries,  imposes  a heavy  burden 
upon  the  program  management.  This,  Volume  IV  of  the  IPCS  final  report,  documents  the  joint 
experience,  conclusion,  and  recommendations  of  the  program  participants  relative  to  the  chronology, 
principles,  and  procedures  to  be  used  in  the  development  of  an  integrated  propulsion  control 
system  of  the  future,  as  they  would  apply  it. 

The  secondary  purpose  of  this  document  is  to  provide  guidance  to  the  development  process 
itself.  Therefore,  we  have  given  strong  emphasis  to  those  activities  that  take  place  very 
early  in  the  program. 

We  have  described  a successful  methodology  that  can  be  applied  in  the  development  of  an  integrated 
propulsion  control  system  for  a high  performance  aircraft  of  the  future.  It  is  assumed  that  a 
new  engine  will  be  developed  for  this  aircraft  and  that  this  engine  and  the  inlet  will  be 
controlled  by  a digital  electronic  computer  supported  by  appropriate  electronic,  electrohydraulic, 
and  electromechanical  devices.  The  controls  development  program  activities  treated  in  this 
document  are  summarized  in  Figure  1.1-1. 
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Figure  1.1-1  Integrated  Propulsion  Control  System  Demonstrator  Program 

Although  the  IPCS  program  was  highly  successful,  it  was  a technology  demonstration  program, 
limited  in  scope,  and  greatly  constrained  by  the  pre-existence  of  the  engine  and  aircraft. 

It  is  necessary  to  extrapolate  IPCS  experience  in  the  context  of  subsequent  and  anticipated 
developments  in  order  to  treat  a flight  system  probably  larger  in  scope  and  subjected  to  other 
constraints . 


1.2  OVERVIEW  OF  VOLUME  IV 

The  primary  usefulness  of  this  document  will  occur  in  the  early  stages  of  the  development 
program,  when  many  important  decisions  must  be  made  and  the  supporting  technical  staffs 
may  not  be  fully  organized.  Our  goal  is  to  provide  assistance  in  establishing  the 
philosophy  and  direction  that  will  minimize  program  risk  and  cost. 

Specific  areas  treated  herein  are: 

Program  management 

Development  of  system  requirements 

Control  mode  design 

Software  development 

Hardware  development 

System  integration  and  testing 

We  have  attempted  to  identify  the  most  important  data,  trades,  and  decisions  that  are 
required  in  each  of  these  areas,  and  to  provide  guidance  on  the  approach  to  finding 
the  data  and  making  the  trades  and  the  decisions. 

1.2.1  Program  Management 

The  topics  of  planning,  communication,  assignment  of  responsibility,  and  contractor 
relationships  are  covered  in  the  Program  Management  section. 

Planning  is  the  first  crucial  task  that  must  be  performed  jointly  by  the  organizations 
contemplating  the  system-development  exercise.  It  is  essential  that  all  the 
participants  become  involved  in  the  development  of  a detailed  time-phased  flow  diagram 
that  identifies  the  time  frame  and  the  organization  responsible  for  each  subtask.  Such 
a diagram  is  also  useful  in  estimating  the  resources  and  information  required  to  complete 
each  task. 

The  assignment  of  responsibility  to  each  contractor  team  member  should  be  negotiated 
when  the  program  is  in  the  planning  stage.  These  agreements  should  be  documented  in 
proposals  to  the  customer  and  should  be  reflected  in  the  work  statements  of  the 
several  contracts  when  they  are  let,  if  an  associate  contractor  relationship  is  used 
in  preference  to  the  prime-sub  arrangement. 

Free  interchange  of  information  at  the  working  engineer  level  was  a basic  rule  that 
proved  to  be  invaluable  to  the  IPCS  program.  Discipline  is  important,  but  it  is 
essential  that  it  is  not  restrictive.  This  interchange  will  be  more  and  more 
important  as  the  degree  of  integration  increases.  The  subsystem  designer  must  have 
a good  comprehension  of  the  overall  system. 

1.2.2  Development  of  System  Requirements 

The  "development  of  requirements"  is  a term  applied  to  those  activities  that  lead  to  a 
detailed  set  of  preliminary  hardware  and  software  requirements.  The  outputs  of  the 
activities  discussed  under  this  heading  are  the  following: 

A baseline  controller  configuration 
Definition  of  sensors  and  actuators 
required  for  controller 
implementation 

Electronic  and  physical  interface 
definition 

Computer  processor  capability  requirements 
Reliability  and  safety  requirements 
Power  requirements 

Environmental  control  and/or  tolerance 
requirements 

The  development  of  component  requirements  is  discussed  in  Section  3.3.  Component 
requirements  can  be  established  only  after  the  plant  has  been  defined  and  the 
basic  control  algorithm  has  been  designed.  This  lends  urgency  to  those  activities 
because  detailed  hardware,  software,  and  control  mode  design  cannot  proceed  until 
component  requirements  are  defined.  In  addition  the  maximum  possible  lead  time 
should  be  provided  for  component  development  and/or  procurement. 
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Reliability  requirements.  Section  3.5,  are  a subset  of  the  component  requirements  but 
are  listed  separately  because  of  the  specialized  skills  needed  to  develop  them. 

The  development  of  requirements  is  an  iterative  process  that  benefits  from  the  free 
exchange  of  information.  Initial  requirements  estimates  must  be  examined  and 
updated  as  information  becomes  available. 

1.2.3  Control  Mode  Design 

Control  mode  design  bridges  the  gap  between  the  baseline  design  developed  per 
paragraph  3.3  and  the  detailed  definition  of  control  modes  required  for  physical 
implementation  of  the  system.  The  following  results  are  achieved  in  the  process: 

Confirmation  of  the  baseline  control  algorithm 
Development  of  logic  networks 
Selection  of  gains,  setpoints,  and  compensation 
Corroboration  of  component  accuracy  and  frequency 
response  requirements 

Development  of  failure  detection  and  back-up  modes 

An  analytical  design  team  composed  of  working  level  personnel  from  the  airframe, 
control,  and  engine  companies  should  be  established  to  perform  the  control  mode 
design.  Their  fundamental  design  tool  will  be  a non-linear  digital  dynamic 
simulation  of  the  propulsion  system  and  relevant  portions  of  the  airframe.  A 
hybrid  simulation  used  for  specialized  studies  and  software  checkout  and  linear 
models  used  for  loop  design  are  derived  from  the  digital  simulation.  The  rapidly 
developing  science  of  optimal  controls  should  be  explored  for  loop  design. 

1.2.4  Software  Development 

Conventional  software  development  techniques  were  applied  successfully  during 
the  IPCS  program.  It  was  concluded  that  verification  testing  should  be  done  with 
the  operational  hardware  and  with  the  control  loop  closed  by  a real-time  plant 
simulation.  Field  support  during  ground  testing  should  include  at  least  one 
software  engineer  to  support  test  shift  operations  and  one  experienced  individual 
whose  primary  responsibility  is  to  desiqn  software  modifications  and  maintain 
| documentation. 

1.2.5  Hardware  Development 

Hardware  development  covers  the  specification,  design,  procurement  or  fabrication, 
and  testing  of  components  that  meet  the  requirements  discussed  in  paragraph  1.2.2. 

It  is  commonly  found  that  the  components  needed  to  meet  specific  requirements  are 
unavailable,  impossible  with  existing  technology,  or  more  expensive  than  anticipated. 
The  requirements  must  be  reassessed  and  the  options  weighed.  Hopefully  the  require- 
ments can  be  relaxed.  Otherwise  the  penalty  must  be  assumed.  If  this  is  unfeasible 
it  may  be  necessary  to  redesign  the  control  mode  to  eliminate  the  offending  require- 
ment. A program  to  generate  new  component  technology  should  be  attempted  only  as  a 
last  resort. 


1.2.6  System  Integration  and  Test 

I We  strongly  support  the  step-by-step  approach  to  system  integration  and  testing. 

Interface  tests  should  be  initiated  by  the  controls  manufacturer  as  soon  as  the 
hardware  and  software  components  become  available.  Final  pre-delivery  checkout 
of  software  should  be  performed  on  the  actual  control  computer  with  its  interface 
unit,  using  a real-time  simulation  to  close  the  loop. 


The  IPCS  fuel  bench  test  procedure  is  sound  and  is  adaptable  to  other  programs. 
In  addition,  a closed-loop  wind-tunnel  test  of  a fully  actuated  inlet  model  is 
recommended,  particularly  if  the  inlet  operates  in  a mixed-compression  mode. 
Sea-level-static  testing,  followed  by  altitude  testing  of  the  demonstrator 
engine  is  recommended;  initial  tests  would  be  run  using  a bell-mouth  inlet.  The 
introduction  of  a boiler-plate  version  of  the  flight  inlet  during  the  sea-level 
test  program  is  desirable,  particularly  if  the  Inlet  is  actuated  during  ground 
or  low  speed  flight  operation. 
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It  is  recommended  that  a data  recording  package  be  designed  for  use  in  ground  and  flight 
tests,  together  with  a mobile  data  processing  van  that  is  moved  from  facility  to  facility 
during  the  entire  test  program.  This  approach  will  provide  rapid  data  turnaround  through 
the  use  of  an  on-site  dedicated  data  processing  facility  and  eliminate  the  requirement 
for  interfacing  with  the  facility  data  processing  systems. 

One  of  the  conclusions  drawn  from  the  program  is  that  the  tests  were  too  closely  spaced 
on  the  schedule;  there  was  not  enough  time  between  the  tests  to  absorb  the  results. 
Another  conclusion  was  that  control  mode  development  would  be  facilitated  by  a real-time 
plant  simulation  at  the  test  site  to  close  the  control  loops  for  software  checkout. 


2.0  PROGRAM  MANAGEMENT 

Development  of  an  integrated  control  system  requires  adaptation  of  management  disciplines 
to  the  special  situation  in  which  equipment  built  by  one  contractor  will  operate  under 
the  influence  oT  a controller  designed  and  built  by  another  contractor  to  a set  of 
requirements  established  by  a contractor  team.  Subjects  which  must  be  given  special 
consideration  are: 


Planning 

Resources 

Responsibility 

Communication 

The  main  objective  of  the  management  effort  is  to  ensure  that  available  resources 
are  judiciously  applied  to  achieve  the  end  objective  most  effectively.  Existing  corporate 
organizations  generally  provide  the  discipline  and  structure  which  are  necessary  for 
effective  control,  but  modifications  to  commonly  accepted  practice  may  be  needed  for 
smooth  running  efficiency.  The  capabilities  and  resources  of  each  of  the  contractors 
must  be  recognized  and  used.  Duplication  of  effort  must  be  avoided,  and  opportunities 
for  redistribution  of  work  outside  of  traditional  responsibility  boundaries  must  be 
taken  when  it  is  apparent  that  benefits  in  efficiency  or  productivity  will  result. 

2.1  PLANNING 

Careful  planning  is  crucial  to  any  program.  It  is  particularly  important  in  the 
development  of  an  integrated  system  which  depends  upon  the  interaction  of  several 
contractors  and  agencies.  Efficiency  of  operation  depends  upon  distribution  of 
tasks  over  the  period  of  time  available. 

2.1.1  Time  Line 

A sequence  of  64  events  has  been  set  down  in  the  time  line  shown  in  Figure  2.1-1.  Five 
overlapping  major  phases  have  been  split  out  covering  the  period  of  time  which  starts 
with  the  identification  of  a system  application,  and  ends  with  the  selection  of 
contractors  to  proceed  with  the  development  of  the  system  prototype.  The  time  line  has 
been  structured  to  fit  an  engine/supersonic-inlet  integration  program.  If  the  program 
involved  other  integration  aspects,  e.g.,  a subsonic  VSTOL  program,  it  would  be 
necessary  to  substitute  different  events. 

The  end  point  has  been  selected  to  correspond  to  the  end  points  of  the  System  Develop- 
ment Program  shown  in  Figure  58  of  reference  1,  reproduced  here  as  Figure  2.1-2.  The 
five  major  phases  are  System  Definition  and  Preliminary  Design,  Requirements,  System 
Design,  Fabrication  and  Component  Test,  and  System  Demonstration. 

Analysis  is  not  shown  as  a phase,  since  it  is  necessary  to  continue  a comprehensive 
analysis  for  the  duration  of  the  development  of  the  system. 

Simulation,  controls  analysis,  performance,  test  data  reduction,  must  proceed  at 
different  levels  of  emphasis  to  support  the  design,  build  and  test  of  the  system. 

A program  flow  chart,  which  shows  ho'i  the  program  functions  flow  is  shown  in  Figure 


This  initial  scheme  will  obviously  need  to  be  converted  to  a more  detailed 
multi-tier  schedule,  that  will  permit  precise  tracking  of  milestones  which  measure 
progress  and  accomplishments  of  the  program. 

2.1.2  Resources 

It  is  not  possible  to  define  the  scope  of  the  program  or  the  participation  of  the 
contractors  without  due  concern  for  possession  and  scheduling  of  resources  such  as  test 
facilities  and  computers. 

Technological  capability  must  also  be  examined,  such  as  the  design  and  manufacture  of: 

Airframes 

Engines 

Control  systems 

Electronics 

Software 
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Figure  2.1-2  Timing  and  Decision  Points  to  Contract  Item  Specification 


Figure  2.1-3  Demonstrator  Program  Flow  Chart 


In  many  cases  the  facilities  and  capability  are  owned  by  the  government.  Availability 
and  possible  use  of  these  facilities  should  be  explored  in  depth. 

2.2  ASSIGNMENT  OF  RESPONSIBILITIES 

During  the  pre-contractual  or  competitive  phase  of  system  development,  prospective 
participants  should  work  out  agreements  covering  the  division  of  the  task.  In  interest 
of  continuity  it  is  desirable  to  establish  relationships  that  will  endure,  essentially 
unchanged,  throughout  the  development  and  preproduction  cycle,  acknowledging  the 
phasing  of  the  work  and  scheduling  of  facilities  and  manpower. 

2.2.1  Company  Relationships 

Contractual  relationships  among  companies  will  probably  be  determined  by  the  nature 
of  the  anticipated  procurement,  as  opposed  to  the  relationship  which  may  seem  most 
attractive  for  the  development  of  the  integrated  propulsion  control.  However,  the 
working  relationships  should  be  established  and  documented  consistent  with  the 
contractual  constraints. 

2.2.2  Integrating  Contractor 

One  contractor  must  have  responsibility  for  making  overall  system  studies  and  decisions. 
This  contractor  should  have  the  responsibility  for  primary  interface  with  the  customer. 
If  a single  prime  contract  is  anticipated,  it  would  be  logical  for  this  respon- 
sibility to  be  assumed  by  the  prime  contractor.  An  integration  contractor  is  another 
possibility.  One  of  the  associate  contractors  might  have  this  responsibility  in  the 
case  of  a typical  government  weapon  system  procurement.  If  the  customer  elects  to 
retain  this  responsibility,  he  should  be  prepared  for  substantial  involvement  with 
the  contractors  in  all  aspects  of  their  work;  technical,  contractual,  and  financial. 

The  importance  of  open  communication  in  all  links  cannot  be  too  strongly  stressed. 
Configuration  control  of  all  components  of  the  system, hardware  and  software,  is 
another  important  responsibility. 

The  IPCS  program  was  based  on  a prime/subcontract  relationship  in  the  belief  that 
it  provided  the  most  efficient  contracting  mechanism.  All  the  participants  contributed 
to  program  direction,  but  control  remained  in  the  hands  of  the  prime  contractor  with 
direct  responsibility  to  the  customer  agency  This  provided  a very  direct  mechanism  for 
rapid  decision  making.  Justification  for  this  approach  lies  in  the  fact  that  the  3- 
year  program  was  completed  precisely  on  the  time  schedule  of  the  original  contract.  The 
intercompany  relationships  are  shown  in  Figure  2.2t1. 

2.2.3  Division  by  Product  Lines 

The  development  of  an  integrated  propulsion  control  system  can  be  divided  into  four 
areas: 


Engine  control  modes 
Inlet/airframe  control  modes 
Control  hardware 
Software 

It  would  be  natural,  although  not  essential,  that  these  packages  be  divided,  intact, 
among  the  program  participants.  Cooperation  between  companies  and  inter -group  flow 
of  communication  are  essential.  It  is  an  absolute  requirement  that  no  unilateral 
decisions  be  made  in  one  area  that  may  impact  another  area. 

The  control  hardware  may  be  divided  into  sensors  and  actuators  on  the  engine,  sensors 
and  actuators  in  the  Inlet  and  airframe, and  the  computer  hardware.  Engine  and 
airframe  manufacturers  must  retain  ultimate  responsibility  for  the  structural 
integrity  and  operational  characteristics  (e.g.,  accuracy,  band  pass)  of  their 
respective  sensors  and  actuators  as  well  as  the  responsibility  for  plumbing, 
mounting  brackets,  etc.  Responsibility  for  signal  conditioning  should  be  extended 
to  include  transducer  excitation. 


Figure  2.2-1  Contractor  Relationships 
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There  are  definite  advantages  to  having  computer  hardware  and  software  supplied  by  the  same 
organization.  The  control  algorithm  is  only  one  of  several  essential  program  modules. 

Some  of  these  modules  are  hardware  peculiar  and  can  have  a strong  effect  on  the  implementation 
of  the  control  modes. 

2.2.4  Division  by  Technology 

Integrated  propulsion  control  development  could  also  be  divided  by  technology  areas  to 
take  advantage  of  possible  specialized  skills  of  the  participants.  This  situation  has 
particular  application  where  more  than  one  of  the  contractors  have  similar  capabilities, 
for  example: 

Control  mode  design 
Electronic  design  and  manufacturing 
Mechanical  design  and  manufacturing 
Software  engineering 

The  important  objective  of  this  approach  is  to  maximize  the  integration  and  avoid 
duplication.  This  is  a perfectly  viable  approach  that  has  some  advantages  over  the 
product  line  approach  if  the  organizational  and  contractual  difficulties  can  be 
overcome.  Cooperation  among  the  contractors  is  essential.  A good  example  is 
control  mode  design.  In  practice,  the  group  charged  with  control  mode  design  would 
probably  include  representatives  of  engine,  airframe  and  controls  manufacturers. 

In  the  IPCS  program,  controls  development  responsibility  was  divided  as  follows: 

Control  mode  configuration  - P&WA 
Compensation  Design  - Boeing 
Electronics  and  Software  - Honeywell 
Simulation  - all  contractors 

Under  this  arrangement  simulation  was  performed  by  each  of  the  contractors  as  required 
to  support  the  other  functions.  Analysis  must  continue  to  a necessary  degree  throughout 
all  phases  of  the  program.  The  contractors  participated  in  the  analytical  work  of 
the  program  as  shown  in  Figure  2.2-2. 

2.3  COMMUNICATION 

Communication  among  all  parties  down  to  the  working  engineer  level  is  an  essential 
function  that  requires  support  from  management.  All  companies  have  developed 
disciplines  and  restrictions  on  the  transmittal  of  information  which  are  suited  to 
their  own  situation,  which  are  necessary  for  commercial  and  national  security, 
public  relations,  and  other  responsibilities.  These  regulations  must  be  adapted 
to  the  special  needs  of  the  integrated  propulsion  control  system  development. 

2.3.1  Protection  of  Proprietary  Information 

Agreements  should  be  developed  to  ensure  proper  protection  of  proprietary  information. 
Intercompany  agreements  are  essential  to  allow  enough  information  to  flow  to  do  the 
job  efficiently  and  conveniently.  The  point  is  to  establish  the  channels  for 
communication  of  all  material,  and  to  provide  the  necessary  mechanism  to  prevent 
improper  use  of  specific  knowledge.  A good  example  is  a computer  program  which 
may  be  capable  of  specialized  computations.  Two-party  agreements  were  executed 
between  Boeing  and  P&WA,  Boeing  and  Honeywell,  Honeywell  and  P&WA,  and  Boeing  and 
General  Dynamics,  in  order  to  facilitate  information  transmittal  in  which  each 
company  agreed  to  use  transmitted  data  only  for  the  intended  purpose  to  protect 
it,  and  not  to  make  any  unauthorized  use  of  it.  In  each  case,  the  two  companies 
made  reciprocal  agreements  and  defined  the  formalities  to  be  observed. 

2.3.2  System  Definition  and  Configuration  Control 

The  contractors  must  be  able  to  depend  upon  being  able  to  work  from  a consistent 
definition  of  the  system  at  all  times.  It  is  thus  essential  to  maintain  a formal 
system  of  documentation  which  the  technical  participants  can  use  without  inconvenience. 

Such  a system  is  outlined  in  Figure  2. 3-1. Some  of  these  documents  are  normal 
requirements  in  the  formal  documentation  of  the  contract,  others  are  not.  The 
document  control  mechanism  must  be  flexible  and  easily  used  in  order  to  ensure 
that  updates  are  made  when  needed.  The  documentation  system  is  the  key  to 
effective  configuration  control. 
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Analytical  Control  Design  Plan 


•OE lllG/ttOriC YWCLL/PRATT  ( WHITNEY 


Figure  2.3-2  IPCS  Coordination  Memo  Form 


A configuration-controlled  glossary  of  terms  should  also  be  provided  in  the  Systems 
Definition  document.  Use  of  these  terms  should  be  required  by  all  development  areas 
to  ensure  compatibility. 


2.3.3  Costs  and  Schedules 

Formal  and  informal  transmittal  of  cost  and  schedule  data  are  essential  for  the  program 
to  be  kept  under  control.  Routine  monthly  transmittal  of  information  is  not  adequate 
for  precise  control,  and  informal  supporting  communication  agreements  may  have  to  be 
set  up  to  provide  cost  control. 

Visibility  is  necessary  within  a time  frame  to  provide  response  which  will  control  the 
costs.  During  periods  of  heavy  expenditure  rate,  weekly  updates  of  costs  and  schedules 
are  probably  necessary  for  effective  intra-company,  and  inter-company  control. 

2.3.4  Informal  Documentation 

A means  of  rapid  "semi  formal"  documentation  is  necessary  so  that  information  can 
be  transmitted  which  is  not  subjected  to  the  restrictions  resulting  from  contractual 
formality.  Users  of  such  a system  should  understand  that  their  messages  do  not  possess 
contractual  commitment,  although,  obviously  this  does  not  relieve  the  user  from 
responsible  use  of  the  medium. 

2.3. 4.1  Coordination  Memos 

Written  technical  communications  were  handled  with  an  effective  "Coordination  Memo" 
system,  which  was  used  to  exchange  data  and  to  document  telephone  commitments  when 
required.  A simple  format  is  important  to  encourage  free  use  of  this  convenient 
system  and  it  should  be  a vital  part  of  any  cooperative  development  program.  The 
form  used  for  IPCS  coordination  memos  is  shown  in  Figure  2.3-2.  Each  I PCS  coord  memo 
was  sent  by  the  originating  contractor  to  both  of  the  other  major  contractors  on 
the  program.  This  is  considered  an  essential  feature  of  open  communication. 

2. 3. 4. 2 Telephone  Communication 


Pi 


Use  of  direct  verbal  communication  among  team  members  is  essential.  Communication 
by  telephone  played  a major  role  in  the  IPCS  program.  In  order  to  permit  a free 
exchange  of  technical  information,  each  individual  had  to  understand  the  overall 
program  well  enough  to  exercise  sound  judgment  and  make  valid  commitments.  In 
addition,  an  efficient,  internal  telephone  memorandum  system  was  required  to  keep 
key  personnel  advised  of  the  substance  of  the  conversations.  This  technique 
proved  effective  for  the  small  R&D  effort,  but  the  magnitude  of  a major  development 
program  could  reduce  this  procedure  to  chaos  unless  discipline  is  practiced.  In 
that  case,  limiting  the  interchange  to  one  individual  in  each  key  discipline  might 
be  equally  effective  and  should  not  be  a management  burden.  As  an  alternative,  it 
might  be  feasible  to  assign  to  each  individual  a counterpart  in  the  other  company(s) 
that  he  may  contact  freely. 
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A small  effort  to  use  commonly  available  facilities  such  as  speaker  phones, 
three  party  conference  calls  and  fascimile  machines  can  considerably  enhance  the 
rate  at  which  problems  are  dealt  with.  Again  It  usually  falls  upon  program  managers 
to  provide  such  facilities  and  encourage  their  use. 


3.0  DEVELOPMENT  OF  REQUIREMENTS 

The  “development  of  requirements"  is  a term  applied  to  those  activities  that  lead  to  a 
detailed  set  of  preliminary  hardware  component  and  subsystem  requirements  and  software 
requirements.  The  major  activities  covered  under  this  heading  are  the  compilation  of 
data,  preliminary  design  of  control  modes,  and  trade  studies.  These  activities  should 
begin  with  the  release  of  the  Development  Plan  (see  the  time  line  in  Figure  2.1-1)  and 
should  proceed  concurrently  with  the  preliminary  design  of  the  engine  and  airframe. 
Basically,  they  bridge  the  gap  between  the  preliminary  system  definition  and  hardware 
and  software  design  and  procurement  activities.  The  output  of  the  activities  discussed 
in  this  heading  will  be  the  following: 

A baseline  controller  configuration 

Definition  of  sensors  and  actuator s required  for  control  implementation 

Electronic  and  physical  interface  definition 

Computer  processor  capability  requirements 

Reliability  and  safety  requirements 

Power  requirements 

Environmental  control  and/or  tolerance  requirements 

These  activities  will  last  approximately  a year.  Considerable  interaction  between 
control  and  performance  groups  should  occur  during  this  period  for  two  reasons:  1) 

To  ensure  that  plants  are  controllable  to  the  degree  necessary  to  provide  the 
performance  levels  being  predicted  by  the  performance  group.  2)  To  ensure  that 
performance/stability  groups  utilize  the  full  range  of  flexibility  offered  by 
sophisticated  controls.  At  the  end  of  this  time,  a cost  estimate  will  be  possible 
and  a contractor  review  should  be  conducted  to  evaluate  the  suitability  of  the 
baseline  controller. 

3.1  PLANT  DEFINITION  DATA 

The  paragraphs  below  define  the  major  portion  of  the  information  about  the  plant- 
engine,  inlet,  and  relevent  portions  of  the  airframe  - that  is  required  to  perform 
the  design  and  preliminary  development  of  an  integrated  propulsion  control  system. 

In  some  cases  not  all  the  data  are  required  for  any  one  flight  system  but  it  is 
impossible  to  predict  precisely  which  items  may  be  safely  eliminated  from  the  list. 
Similarly  it  is  impossible  to  define  in  advance  the  accuracy  and  detail  required. 

Hence,  the  following  urgent  recommendations  are  made: 

1.  A document  should  be  established  at  the  preliminary  definition  stage  of 
system  development  to  provide  the  framework  to  assemble  and  disseminate 
the  information  described  above.  The  '.nitial  release  may  be  based  upon 
technology  program  data,  government  specifications,  requests  for 
proposals,  engineering  estimates,  etc.  but  it  should  be  complete  as 
possible.  Sources  of  Information  should  be  clearly  identified;  it 
should  be  the  user's  responsibility  to  ensure  that  the  data  are 
accurate  enough  for  his  requirements. 

2.  Responsibility  for  compiling  and  updating  the  data  document  should  be 
assigned  to  data  administrators  clearly  identified  within  each  company 
that  is  participating  in  the  system  development.  These  people  should 
have  unrestricted  coimunication  with  their  counterparts  in  other 
companies.  Program  managers  within  each  company  should  ensure  that 
their  data  administrators  have  the  support  and  resources  required  to 
carry  out  their  jobs. 

3.  Persons  using  the  data  document  should  communicate  their  requirements 
to  the  data  administrator  as  well  as  transmitting  in  a timely  manner 
all  new  information  that  they  qenerate  or  comes  into  their  possession. 

It  is  not  recommended  that  persons  needing  information  be  prohibited 
from  pursuing  it  on  their  own,  but  rather  that  all  information  be 
retained  in  a common,  standard  pool. 

4.  Data  document  updates  should  be  scheduled  at  intervals  compatible  with 
the  system  development  plan. 

The  paragraphs  below  address  the  information  that  should  be  includeo  in  the  document. 
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3.1.1  Airframe  Definition 


The  airframe  definition  referred  to  here  covers  all  aspects  that  impact  the  propulsion 
controls;  that  is,  a compilation  of  constraints  and  requirements  that  the  propulsion 
system  and  its  controller  must  satisfy  in  order  for  the  aircraft  to  perform  its 
intended  functions.  These  include  the  aircraft  and  mission  constraints,  a description 
of  the  inlet,  a definition  of  airframe  - propulsion  system  interactions,  and  environ- 
mental considerations. 

The  aircraft  mission  definition  includes  the  flight  envelope,  the  point(s)  in  the 
flight  envelope  to  which  the  aircraft  is  optimized,  the  design  mission  profile, 
the  propulsion  system  response  requirements,  and  aircraft  constraints.  Some  of  the 
relevant  constraints  are  listed  in  Table  3.1-1. 

There  is  considerable  current  interest  in  the  use  of  the  propulsion  system  to  augment 
the  aircraft  lift  and/or  control  forces.  The  concept  is  so  new  that  it  is  impossible 
to  define  positively  the  data  that  will  be  required.  However,  some  candidates  are 
listed  in  Table  3.1-2. 

Table  3.1-1  Aircraft  and  Mission  Constraints 


Maneuver  Limits 
Noise  and  Emission  Limits 
Safety  Restrictions 
Reliability  Requirements 
Noise  Abatement 
Boundary  Layer  Blowing 
Flight  Control  Augmentation 
Location  of  Engines 


Crew  Size 

Ground  Servicing  Requirements 

Ships  Power 

Operability 

Thrust  Vectoring 

Customer  Bleed 

Component  Environment 


Table  3.1-2  Airframe-Propulsion  Interaction 


Propulsion  system  drag  characteristics 
Inlet  spillage  drag 
Bypass  drag 

Boundary-layer  bleed  drag 

Aft-end  drag  - effect  of  variable  nozzle,  blow- 
in  doors,  etc. 

Ingestion  of  hot  gases 

Effect  of  propulsion  forces  on  aircraft  stability 
and  control 

Effect  of  propulsion  flowfield  on  aircraft  lift, 
drag,  stability,  and  control 


3.1.2  Engine  Definition 

The  typical  engine  development  process  starts  with  a set  of  mission  requirements  that 
serve  as  criteria  for  engine  cycle  and  configuration  studies.  A controls  observer  in 
the  cycle  selection  procedure  would  be  most  useful.  Possible  constraints  in  control 
implementation  should  be  a factor  during  cycle  selection  to  ensure  that  propulsion 
system  goals  are  achievable. 

These  advanced  studies  eventually  lead  to  selection  of  an  optimum  cycle  and 
configuration,  and  it  is  then  that  sufficient  information  should  be  available  to 
begin  the  control  development  process,  as  indicated  in  Figure  3.1-1.  When  the 
engine  cycle  and  configuration  are  selected,  the  following  Information  Is  generally 
known: 
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Figure  3.1-1  Influence  of  Engine  Definition  on  Control  Requirements 
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Figure  3.1-2  Example  System  Interconnections 


Engine  operational  requirements  (thrust,  TSFC,  weight,  thrust  response, 
range  of  operation,  stability  requirements  and  mechanical  design 
limits). 

Engine  controlled  variables  (fuel  flow,  stator  vane  angle,  nozzle  area, 
turbine  area,  compressor  bleeds). 

Options  for  sensed  variables  (pressure  ratios,  corrected  speeds,  temperatures, 

Mach  numbers,  etc.) 

Engine  rating  options  (turbine  discharge  pressure  ratio,  turbine  inlet 
temperature,  low  rotor  speed,  etc.). 

Ranges  of  sensed  variables. 

This  information  is  sufficient  to  begin  control  mode  studies.  In  general  each 
controlled  variable  will  be  used  in  an  integrated  manner  to  achieve  overall 
propulsion  system  goals  rather  than  as  a fix  for  specific  problems.  Thus  compressor 
bleeds  are  used  to  provide  performance/stability  trades  in  flight  rather  than  just  as 
a means  of  providing  surge  margin  during  starting. 

Engine  rating  requirements  such  as  turbine  inlet  temperature  or  corrected  speed  limits 
influence  the  selection  of  steady  state  governing  parameters  and  sensor  requirements. 

In  the  early  stages  of  engine  development,  a dynamic  engine  simulation  (Section  4.1.1) 
is  used  to  predict  steady  state  and  transient  engine  operation  to  evaluate  control 
modes  and  generate  schedules.  The  simulation  includes  estimated  engine  component 
characteristics  that  become  better  defined  as  development  progresses  through 
component  rig  testing.  As  the  simulation  is  updated  to  incorporate  component  test 
results,  the  control  studies  are  reviewed  to  ensure  that  the  control  operation 
meets  all  requirements.  Typical  component  characteristics  that  influence  control 
design  are  listed  below. 

Compressor  stall  boundaries  for  limiting  transient  fuel  flow. 

Inlet  distortion  tolerance  characteristics  and  airflow  range. 

Burner  lighting  characteristics  for  fuel  management  during  the  starts. 

Compressor  bleed  requirements  for  starting  and  stall  protection. 

Optimum  afterburner  fuel  distribution  for  schedule  development. 

Turbine  inlet  temperature  limits  for  limiting  transient  fuel  flow 
Rotor  speed  and  burner  pressure  limits. 

It  is  important,  that  the  influence  of  projected  sensor  and  computational  accuracy  be  included 
even  during  the  preliminary  computer  studies  to  determine  if  the  candidate  control 
modes  are  feasible. 

Refinements  and  modifications  are  made  after  the  engine  test,  but  these  changes  have  a 
smaller  effect  on  control  design  than  the  earlier  phases  of  engine  development. 

The  IPCS  control  development  began  after  the  TF30-P-9  engine  was  in  service,  and  control 
requirements  were  well  defined  at  the  outset.  A dynamic  simulation  was  developed  from 
component  characteristics  and  refined  until  it  closely  approximated  engine  operation  at 
sea  level  static  and  at  altitude.  New  control  modes  were  developed  and  schedules  were 
generated  to  meet  established  control  requirements  with  the  aid  of  the  simulation.  A 
comparison  of  IPCS  control  and  new  control  development  in  relation  to  engine  development 
is  shown  in  Figure  3.1-1. 
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3.1.3  Electronic  Interface  Definition 

The  electronic  interface  definition  portion  of  the  Plant  Definition  will  be  the 
result  of  the  trade  studies  by  the  intercompany  team  as  discussed  at  the  beginning  of 
this  section.  These  experts  will  address  themselves  to  developing  the  optimum  baseline 
sensor,  actuator,  power  air-frame  electronic  interface,  and  to  the  adequate  definition 
of  these  interfaces.  The  definition  of  interfaces  will  also  include  a baseline 
definition  of  the  controller:  installation,  size,  weight,  power  limitations,  hydraulic 

interface  and  fuel/air  cooling  interface. 

Tables  3.1-3  and  3.1-4  provide  examples  of  I/O  interface  tables  that  provide  the 
type  of  data  required  for  the  electronic  interfaces.  Tables  3.1-5  provides  a 
table  of  requirements  for  the  electronic  controller.  Figure  3.1-2,  3.1-3,  and  3.1-4 
show  examples  of  a controller  block  diagram  and  pictorials  of  the  mechanical 
configuration  for  the  electronic  controller.  These  tables  and  figures  demonstrate 
the  type  of  Electronic  Interface  Definition  required  to  commence  design  of  the 
electronic  controller.  Tables  and  figures  similar  to  these  were  developed  during 
the  IPCS  Program  to  establish  an  early  definition  of  the  plant  and  the  electronic 
controller/plant  interface  requirements. 

3.2  PERFORMANCE  - STABILITY  TRADES 

The  primary  means  of  effecting  flight  system  performance,  once  the  basic  airframe 
configuration  and  engine  cycle  have  been  selected,  is  in  the  hands  of  the  various 
control  groups.  In  the  case  of  a moderately  complex  system  such  as  the  F-111/TF30 
and  future  Variable  Cycle  Engine  (VCE)  concepts,  the  control  has  an  extremely 
strong  influence  on  performance.  The  basic  goal  is  to  maximize  performance  when 
destabilizing  effects  are  small,  such  as  during  cruise,  and  to  provide  adequate 
stability  during  disturbances  such  as  maneuvers  or  other  transients.  Since 
engine  and  airframe  interactions  affect  both  performance  and  stability,  control 
integration  is  required  to  achieve  this  goal.  The  advent  of  relatively  reliable 
digital  computers  has  made  practical  the  sensing  and  logic  necessary  to  perform 
the  trade  in  real  time.  This  trade,  made  in  flight,  was  the  primary  means  used 
to  improve  the  performance  of  the  F-111/TF30  system  on  this  program. 

Control  concepts  to  apply  this  capability  include  the  following: 

Engine  bleed  only  when  near-instability  exists  as  measured  by  some 
direct  or  indirect  means.  Engine  thrust  and  fuel  consumption 
during  cruise  should  be  improved. 

Direct  control  of  afterburner  fuel -air  ratio  and  fan  match  to  produce 
both  performance  and  stability  benefits  while  operating  closer 
to  the  limits. 

Direct  measurement  of  critical  variables  to  control  fuel  flow  during 
engine  transients  to  improve  transient  times  by  operating  closer 
to  the  compressor  stability  and  turbine  temperature  limits. 

Inlet  air  bleed  and  geometry  resets  during  measured  disturbances. 

To  factor  the  control  capabilities  and  limitations  into  the  design  process,  control 
specialists  must  participate  in  the  propulsion  system  design  activity.  Basic 
decisions  at  the  propulsion  component  level,  such  as  inlet  sizing  and  compressor 
surge  margin  should  be  made  with  full  visibility  Into  control  accuracy  and 
response  capabilities. 

The  performance  benefit  of  additional  variable  geometry  must  be  assessed  with 
consideration  for  the  impact  on  inlet,  engine  and  control  system  cost,  weight 
and  reliability.  The  results  of  these  objective  trade  studies  will  support  the 
design  decisions  that  must  be  made  throughout  the  preliminary  design  of  the 
propulsion  system. 
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Table  3.1-4  Sample  Output  Signal  Table 
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Table  3.1-5  Sample  Preliminary  Design  Requirements  for  an  Electronic  Controller 


Example  Requirements  for  the  Electronic  Controller 


Design  Aim  Requirements 


Production  Flight  System  Cost:  40K  maximum 

Weight:  20  lb.  maximum 

Size:  (3  x 12  x 6)  in.  maximum 

Power  Dissipation:  100  W maximum 

Reliability,  MTBF:  30,  000  hr 

(Use  selective  redundancy  and 
Provide  fail/safe  back-up  system) 
Maintainability: 

(Provide  BITE  and  condition  monitor) 
(Replacement  time:  1 hr  maximum) 


Environmental  Requirements 


Temperature:  -65'  to  +185'  F 

(Heat  exchanger  and  fuel/air  cooling 
provided) 

Vibration:  ±15C!  (HO  to  2000  c.p.  s.  with  two  minute  dwell 

at  resonances)  (Aero-flex  Vibration  Isolators 
provided) 

Altitude:  to  100,  000  ft 
Humidity:  Up  to  100% 

Shock:  1 5G  for  I I msec  (3  axis) 


Electrical  Interface  Requirements 


Inputs:  Per  Table- 

Outputs:  Per  Table 

Power:  Dedicated  3?  alternator  supplied 

Cabling:  l se  fiber  optics  where  possible 


Pneumatic /I  iydraulic  Inte  rface  Requi  cements 

Cooling  fuel:  See  related  spec 

Pressure  probes:  See  related  spec 


TEMPERATURE:  RESISTANCE  BULBS 
AND  THERMOCOUPLE 


Packaging  Diagram  (S 


Figure  3.1-4  Example  Electronics  Block  Diagram 


The  performance-stability  trades  are  conducted  during  the  System  Definition  Phase  identified 
on  the  time  line  in  Figure  2.1-1.  The  study  logically  coincides  with  and  supports  the 
cycle  screening  phase  of  the  propulsion  system  integration  effort  as  identified  in  Figure 
58  of  reference  1.  Typical  control  system  support  tasks  include: 

List  candidate  signals  with  the  type  of  sensor,  reliability,  accuracy, 
and  response  required  to  exercise  the  performance/stability  trades  in 
real  time.  These  signals  may  alternatively  be  computed  in  the 
controller  or  obtained  from  some  aircraft  subsystems  other  than  the 
inlet  or  engine;  for  example,  flight  control  system,  or  the  central 
air  data  computer  (CADC). 

Investigate  the  actuation  capability  required  to  implement  the  candidate 
performance/stability  trade  in  flight.  When  it  has  been  determined 
that  sensor,  actuator,  and  computer  requirements  are  all  within  the 
existing  or  projected  state-of-the-art,  a control  loop  may  be  designed, 
as  described  in  Section  3.3,  and  evaluated  to  determine  whether  the 
performance  gain  justifies  the  additional  complexity. 

The  digital  propulsion  system  simulation  is  an  excellent  tool  to  support  the  performance- 
stability  trades.  Various  control  options  may  be  exercised  and  evaluated  quickly,  with 
a clear  insight  into  the  performance  and  stability  impact. 

Three  factors  greatly  influenced  the  selection  and  development  of  new  control  modes 
in  the  IPCS  program:  (1)  Due  to  the  exploratory  nature  of  the  program,  performance 

and  stability  trades  were  conducted  to  determine  whether  a candidate  control  loop 
offered  a potential  benefit  rather  than  to  estimate  the  magnitude  of  the  benefit. 

(2)  There  was  a requirement  to  mount  probes  and  sensors  on  the  engine  by  modification 
of  existing  hardware  without  impacting  structural  integrity.  (3)  The  selection  of 
transducers  was  limited  to  those  currently  available.  The  development  of  IPCS 
control  modes  that  affect  performance  or  stability  are  described  below: 

Bleeds  Controlled  by  Distortion  Tolerance  - The  concept  of  direct 
parameter  sensing  was  applied  to  the  bleed  control  loop.  The  key 
trades  in  developing  the  loop  were  the  method  of  sensing  the  distortion 
level  with  a minimum  of  probes  (discussed  in  paragraph  4.5.2)  and  the 
calculation  of  engine  distortion  tolerance  to  determine  the  distortion 
level  at  which  the  bleeds  would  be  commanded  open.  The  margin  was 
influenced  by  the  rate  of  distortion  increase  during  maneuvers,  the 
rapidity  of  bleed  opening  and  the  hysteresis  required  to  prevent  bleed 
oscillation.  Bleed  opening  characteristics  determined  from  TF30 
development  testing  were  included  in  the  propulsion  system  dynamic 
simulation.  Airplane  attitude  change  and  engine  transients  were 
simulated  to  define  the  minimum  distortion  margin  consistent  with 
desirable  bleed  operation. 

Airflow  Control  - Engine  development  experience  indicates  that  total 
airflow  was  reliably  synthesized  using  engine  pressure  ratio  and  low 
rotor  corrected  speed.  Digital  simulation  experience  indicated  that  the 
synthesized  total  engine  corrected  airflow  mode  performed  well  during 
simulated  altitude  conditions.  This  was  indicated  by  engine  airflow 
being  maintained  at  the  respective  limits  when  power  was  set  at  idle, 
or  at  military  or  above. 

Exhaust  Nozzle  Control  - The  fan  match  for  afterburner  operation, 
measured  in  terms  of  engine  pressure  ratio  and  total  corrected  airflow, 
was  used  to  control  exhaust  nozzle  area.  Control  of  area  using  the 
fan  match  mode  satisfied  the  requirements  for  engine  stability, 
thrust,  turbine  temperature,  and  inlet  corrected  airflow. 

Engine  Transients  - The  limitations  on  engine  acceleration  are  high 
compressor  stability  and  turbine  inlet  temperature.  Decreases  in 
acceleration  time  are  achieved  at  the  expense  of  compressor  stability 
and  turbine  thermal  stress.  However,  if  compressor  stability  and 
turbine  temperature  are  measured  directly,  then  error  in  these 
parameters  introduced  by  indirect  scheduling  can  be  minimized.  Previous 
studies  in  the  industry  indicated  compressor  discharge  Mach  number  had 
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potential  for  controlling  compressor  excursions  during  transients.  In 
addition,  the  Air  Force  and  Honeywell  had  developed  a fluidic  turbine 
inlet  temperature  measuring  system.  The  results  of  this  previous  work 
suggested  modes  to  limit  high  compressor  discharge  Mach  number  and 
turbine  inlet  temperature  during  engine  accelerations.  These  were 
developed  using  the  digital  simulation  to  generate  the  mode  requirements 
and  schedules  needed  for  demonstration  during  engine  test. 

Low  compressor  stability  and  burner  flameout  limit  engine  deceleration 
rates  - The  engine  deceleration  limit  provides  flameout  protection, 
but  low  compressor  instability  occurs  at  some  flight  conditions.  Again 
taking  advantage  of  previous  work,  the  low  compressor  discharge  Mach 
number  was  selected  as  the  stability  protection  parameter. 

The  inlet  phenomena  that  tend  to  limit  or  degrade  engine  and  vehicle  performance  are 
flow  distortion,  pressure  recovery,  flow  oscillations  (e.g.,  turbulence  and  buzz) 
inlet  unstart  (mixed  compression  inlet),  and  bypass  and/or  bleed  drag.  Several  of 
these  phenomena  are  fundemental  to  the  engine/air  frame  integration  problem  and 
are  treated  in  depth  by  Brimelow  (reference  1).  The  inlet  subsystem  must  also  be 
able  to  tolerate  the  disturbances  listed  in  Table  3.2-1.  In  general,  the 
occurrance  or  severity  of  these  phenomena  is  a function  of  flight  condition  so 
that  fixed  stability  margins  built  into  the  system  to  tolerate  worst  cases  will 
penalize  the  aircraft  over  the  entire  flight  envelope.  Methods  of  sensinq  the 
disturbances  must  therefore  be  developed.  In  the  event  that  the  disturbances  cannot 
be  sensed,  predicting  and  correcting  for  them,  open  loop,  is  the  less  desirable, 
low  performance  alternative. 

The  trades  and  selections  made  during  the  IPCS  mode  development  program  were 
consistent  with  its  intent  and  purpose  identified  during  the  study  phase.  The 
simulation  was  used  to  eliminate  some  options  and  provide  the  basis  for  final 
mode  selection  as  agreed  upon  at  the  Preliminary  Design  Review.  No  charges  were 
made  to  the  basic  engine  mode  during  Final  Design,  except  as  required  for  schedule 
definition,  logic  refinement,  and  failure  analysis. 


Table  3.2-1  Inlet  Disturbances 


External  disturbances 
Gusts 

Aircraft  angle-of-attack  and  yaw 
Hot  gas  reingestion 
Weapons  firing  or 
launching  of  stores 
Major  Failures 

Engine  shutdown 
Compressor  stall 
Gas  generator  flame-out 
A/B  flame-out 


Engine  corrected  airflow  transients 
Aircraft  maneuvers 
A/B  light-off  or  shut  down 
Temperature  (T2)  transients 


3.3  BASELINE  CONTROL  ALGORITHM 

This  section  treats  the  selection  of  the  fundamental  input-output  relations  that  are 
designed  or  programmed  into  the  control  system;  open-loop  or  closed-loop  control, 
ischronous  or  droop  governors,  etc.  The  design  of  the  control  algorithm  is 
constrained  first  by  the  ability  to  measure  the  requisite  signals.  In  fact  seven 
of  the  eleven  IPCS  gas  generator  control  loops  employed  new  or  unconventional 
control  signals.  In  evaluating  candidate  control  signals,  one  must  remember  to 
include  signal  conditioning  inaccuracy  in  the  error  budget  and  to  allow  for  signal 
conditioning  time  in  the  stability  analysis  (See  paragraph  4. 3. 3. 4.)  After  it  has 
been  determined  that  the  signal  can  be  sensed  with  satisfactory  accuracy  and 
frequency  response,  questions  of  safety,  logic,  etc.  may  be  addressed. 
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It  is  recommended  that  control  algorithms  be  based  as  far  as  possible  upon  existing 
successful  designs  and  that  these  existing  concepts  be  extended  as  appropriate  to 
incorporate  new  signals,  new  actuators,  or  other  novel  features. 

3.3.1  The  Integrated  Control  Algorithm 

The  control  algorithm  may  be  represented  by  a block  diagram  of  the  mode  showing 
the  inputs,  outputs,  and  loops  used  to  control  the  propulsion  system.  The  preliminary 
algorithm  acts  as  a basis  for  a first  pass  estimate  of  hardware  and  software  require- 
ments, and  must  therefore  be  formulated  very  early  in  the  program.  Refer  to  time 
line.  Figure  2.1-1 . 


The  procedure  used  to  develop  the  first  pass  (baseline)  control  algorithm  involves 
reviewing  the  propulsion  requirements  and  determining  answers  to  the  following 
questions : 

1.  What  are  the  performance/stability  goals  of  the  flight  system? 

2.  What  are  modes  of  existing  systems? 

3.  How  can  we  improve  over  the  existing  system? 

4.  What  propulsion  components  require  controlled  positioning? 

5.  Why  are  they  needed? 

6.  What  are  the  constraints? 

Loops  are  added  to  the  control  to  meet  requirements  in  the  most  direct  manner  feasible. 
In  reviewing  the  requirements,  care  should  be  taken  to  relate  each  requirement  to  a 
measurable  criterion  to  determine  whether  the  requirement  is  satisfied.  A review  of 
the  performance  existing  propulsion  systems  and  their  modes  will  indicate  how  well 
that  control  system  met  its  requirements.  Information  of  this  nature  is  invaluable 
as  a basis  for  establishing  mode  concepts  geared  to  improvement. 


The  algorithm  is  formulated  to  provide  the  control  intelligence  to  satisfy  the  require- 
ments of  the  propulsion  system  in  the  most  direct  manner  feasible,  within  the 
constraints  of  component  technology.  If  existing  sensor  and  actuator  technology 
does  not  permit  direct  measurements  to  satisfy  the  requirements,  analysis  is  performed 
to  evaluate  the  performance  benefits  of  new  technology  devices  versus  signal  synthesis 
or  open-loop  schedules.  The  analysis  consists  of  evaluating  the  new  devices  by 
comparing  them  to  existing  hardware,  considering  reliability,  steady  state  accuracy, 
dynamic  response,  cost,  weight, and  risk  to  the  program.  These  factors  must  be 
evaluated  early  in  the  algorithm  design  process  as  the  outcome  will  determine  the 
mode  of  control . Establishing  component  requirements  for  the  engine  in  this 
manner  becomes  a process  iterative  with  the  engine  algorithm  design. 

The  IPCS  mode  used  direct  measurements  of  critical  parameters  to  maintain  engine  limits. 
In  addition  destabilizing  influences  such  as  distortion  were  measured  and  changes  made 
to  accommodate  the  disturbances . The  kpy  IPCS  features  incorporated  in  the  control 
algorithm  were  as  follows: 
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1.  Isochronous  high  rotor  speed  control  for  accuracy  of  speed  control. 

2.  Direct  turbine  inlet  temperature  measurement  for  temperature  limiting 

3.  Total  engine  airflow  synthesis  for  airflow  limiting 

4.  Direct  low  rotor  speed  measurement  for  speed  limiting 

5.  Direct  compressor  discharge  Mach  Number  measurement  for  compressor  stall 
protection. 

The  inlet  fulfills  two  primary  functions  on  the  aircraft;  provide  properly  conditioned 
airflow  to  the  engine  and  minimize  aircraft  drag.  On  some  high-performance  aircraft 
it  interacts  with  the  flight  controls  to  the  point  that  it  may  be  used  to  supplement 
the  normal  control  surfaces  or.  at  the  least,  flight  control  interaction  must  be 
considered  when  the  inlet  control  modes  are  designed. 

In  an  integrated  system,  the  inlet  control  may  act  in  any  one  of  three  ways: 

1.  Position  inlet  surfaces  in  response  to  signals  sensed  locally. 

2.  Develop  information  or  signals  that  are  used  in  the  control  of 
other  subsystems. 

3.  Position  inlet  surfaces  in  response  to  signals  from  other  subsystems. 

All  three  functions  were  performed  by  the  IPCS  inlet  control,  as  discussed  in  volumes 
II  and  III  of  this  report. 
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The  key  integration  features  selected  during  the  IPCS  algorithm  design  process  were  as 
f ol 1 ows : 
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1.  Direct  measurement  of  distortion  for  operation  of  bleeds  to  improve 
distortion  tolerance  only  when  needed. 

2.  Direct  measurement  of  inlet/engine  airflow  to  match  engine  and  inlet 
airfl  ows. 

3.  Direct  measurement  of  buzz  to  provide  automatic  recovery. 

The  integration  features  were  formulated  during  joint  design  sessions  and  were  added  to  the 
control  to  comply  with  the  requirements  of  the  propulsion  system. 

The  preliminary  block  diagrams  issued  at  the  first  tripartite  "Preliminary  Mode  Study  Session" 
had  a format  as  shown  on  Figure  3.3-1.  Diagrams  like  this  were  used  to  determine  the  first 
pass  estimate  of  control  component  and  software  requirements. 

3.3.2  Specialized  Integrated  Control  Loops 

Four  integrated  engine/in’et  control  loops  that  can  be  of  direct  benefit  to  flight  system 
performance  are  described  in  this  section.  Three  of  these  were  demonstrated  in  the  IPCS 
flight  test  program.  Exploratory  work  on  a sensor  to  reduce  the  fourth  to  practice  was 
successful . 

3.3.2. 1 Buzz  Detection  and  Suppression 

e IPCS  provided  the  first  flight  demonstration  of  the  buzz  detector  developed  originally 
tor  the  Supersonic  Transpc  t (SST),  reference  2.  The  essence  of  the  detector  is  a circuit 
that  responds  to  large  amplitude  inlet  pressure  oscillations  over  a frequency  spectrum  that 
straddles  the  anticipated  buzz  frequency.  It  is  not  necessary  to  examine  the  wave  form  of 
any  individual  pressure  pulse.  The  required  response  to  a buzz  signal  is  an  increase  in 
inlet  airflow.  (Some  other  recovery  strategy  may  work  with  other  inlet  designs.)  The  SST 
inlet  increased  airflow  by  opening  bypass  doors;  since  the  F-III  inlet  had  no  bypass  doors, 
buzz  was  suppressed  by  accelerating  the  engine. 

The  success  of  buzz  detector  in  the  IPCS  flight  tests  and  the  SST  wind  tunnel  tests  provides 
confidence  that  buzz  can  readily  be  detected  and  it  can  be  suppressed  by  an  integrated 
propulsion  control  system,  provided  that  a strategy  is  available  that  will  stabilize  the 
flow. 

3. 3. 2. 2 Real-Time  Distortion  Measurement 

The  success  of  the  IPCS  distortion  loop  hinged  on  the  fact  that  the  F-lll  distortion 
pattern  was  consistent  and  repeatable.  This  condition  is  probably  true  of  many  other 
installations.  In  such  cases  it  should  be  possible  to  correlate  signals  from  a small 
number  of  probes  to  an  accepted  distortion  parameter  Note  that  it  is  not  necessary  to 
obtain  correlation  under  all  conditions,  but  only  under  those  conditions  and  for  those 
distortion  levels  where  significant  degradation  of  stall  margin  or  performance  would 
occur. 

A distortion  signal  may  be  used  to  drive  the  inlet,  closed-loop,  to  a low-distortion 
configuration,  or  it  may  be  used  to  drive  the  engine,  open-loop,  to  a configuration 
tolerant  of  distortion.  The  low-distortion  inlet  configuration  must  be  determined 
experimentally.  The  distortion  tolerance  of  the  engine  is  discussed  in  paragraph  3.2.1. 

3. 3. 2. 3 In-fligh*-  Airflow  Optimization 

Inlet  drag  is  generally  considered  to  be  a function  of  the  engine/inlet  airflow  match  and 
not  to  be  subject  to  modulation  by  the  propulsion  control  system.  This  situation  may 
change  when  it  becomes  possible  to  vary  engine  airflow  independently  of  thrust,  or,  more 
precisely,  to  vary  airflow  independently  of  fuel  flow.  A trade  may  then  be  as  indicated 
by  Figure  3.3-2. 
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Figure  3.3-2  Airflow  Trade  Study 


The  shock  probe  design  explored  during  the  baseline  IPCS  flight  tests  (Vol  II,  paragraph 
5. 2. 4. 5)  was  developed  specifically  to  make  inflight  airflow  optimization  possible.  The 
relation  between  the  probe  signal  and  drag  increment  will  have  to  be  determined  experimentally, 
as  will  the  relation  between  engine  thrust  and  airflow. 

It  will  be  noted  that  the  temperature  of  the  transducer  mounted  in  the  probe  base  lagged 
the  free-stream  temperature  by  a significant  amount  (see  Figure  3.4-2).  This  lag  makes  it 
possible  to  consider  the  use  of  an  uncooled  transducer  if  the  aircraft  is  capable  of  only 
a short  supersonic  dash. 

3. 3. 2. 4 Anticipation  Signals 

There  are  many  phenomena  that  induce  changes  in  engine  airflow  and/or  inlet  capture  area; 
afterburner  light-off  or  shut-down,  engine  speed  changes,  resetting  of  compressor  stators 
or  bleeds,  etc.  Most  of  these  either  result  from  engine  control  action  or  are  sensed  by 
the  engine  control  system  before  the  disturbance  propagates  to  the  inlet  and  can  be 
detected  by  sensors  located  there. 

If  the  amplitude  and  rate  of  the  disturbance  are  such  that  it  threatens  inlet  airflow 
stability,  it  is  comparatively  simple,  with  an  integrated  control  system,  to  anticipate 
the  disturbance  in  tne  inlet  control  loop.  The  inlet  geometry  may  then  be  shifted  to 
accommodate  the  transient,  either  ahead  of  time  or  coincident  with  its  arrival. 

The  feasibility  of  this  approach  was  demonstrated  on  the  IPCS.  The  signal  to  the  afterburner 
zone  one  shut-off  valve  (S0V1)  was  used  to  pulse  the  inlet  duct  exit  Mach  number  signal 
(PROEM)  to  anticipate  the  airflow  transient  that  accompanies  afterburner  light -off.  The 
feature  is  diagrammed  in  Figure  3.3-3. 
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Figure  3.3-3  Anticipation  Signal  Used  In  IPCS  Inlet  Control  Loop 


It  will  be  noted  that  the  anticipation  signal  was  used  to  bias  the  inlet  control  signal 
rather  than  to  bias  the  surface  positions  directly.  Our  analysis  indicated  that  this 
approach  is  preferable  because  of  the  non-linearity  between  airflow  increments  and 
surface  positions. 

3.4  COMPONENT  REQUIREMENTS 

The  development  of  component  requirements  involves  the  three-way  trades  between 
performance,  reliability,  and  cost.  This  task  should  be  initiated  formally  as  soon 
as  the  tentative  control  algorithm  is  completed.  It  may  be  advisable  to  make  the 
initial  set  of  requirements  somewhat  rigorous.  These  should  then  be  subjected  to 
regular,  scheduled  reviews  to  ensure  compatibility  within  the  developing  system  and 
to  relax  the  early,  rigorous  requirements  as  far  as  possible  in  the  interest  of 
economy  and  maintaining  schedules. 

3.4.1  Propulsion  System  Components 

The  process  of  defining  component  requirements  starts  with  the  preliminary  control 
algorithm  to  develop  a flow  diagram  that  indicates  the  measurements,  actuators,  and 
interfaces  required.  The  preliminary  algorithm  acts  as  a basis  for  an  initial  estimate 
of  hardware  requirements  that  must  be  followed  by  an  extensive  trade  study  between 
these  requirements  and  hardware  availability.  The  trade  study  identifies  the  hardware 
to  be  desiqned,  fabricated,  and  tested.  The  algorithm  is  then  modified  to  reflect  these 
results. 

Examples  of  trade  studies  that  establish  the  component  requirements  include  the 
following: 

1.  Performance  trades  - After  the  initial  control  signals  are  identified 

from  the  algorithm  it  is  necessary  to  evaluate  each  individual  measurement 
to  determine  whether  the  particular  measurement  could  be  synthesized 
from  other  measurements,  thus  eliminating  the  hardware,  risk  and  cost 
Involved  In  making  the  measurements  and  yet  maintain  the  accuracy  and 
response  for  loop  control. 
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2.  Hardware  trades  - The  hardware  trades  are  really  a trade  between  hardware 
requirements  and  performance  penalty.  It  is  necessary  to  determine  the 
number  of  measurements  required  at  each  station  to  obtain  consistent  and 
repeatable  signals  without  compromising  the  flow  path  or  the  structural 
integrity  of  the  engine. 

3.  Installation  trades  - The  engine  environment  is  one  of  the  first 
considerations  in  determining  engine  component  requirements.  If  the 
control  algorithm  indicates  usage  of  a signal  sensed  at  a location  not 
readily  accessible,  then  a trade  is  made  on  the  design  implementation 
problems  (time,  cost,  complexity,  durability)  and  weighed  against  the 
performance  loss  associated  with  a substitute  measurement. 

Information  flow  diagrams,  which  are  schematics  of  the  control  system  interfaces, 
present  a visual  picture  of  the  component  requirements  and  are  helpful  in  conducting 
trade  analyses.  The  initial  flow  diagrams  are  derived  from  the  engine  control 
algorithm.  The  information  flow  diagram  for  one  of  the  IPCS  control  modes  is  shown 
on  Figure  3.4-1.  The  design  engineer  reviewed  the  diagram  and  listed  all  the 
components  to  indicate  their  performance  requirements. 
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Figure  3.4-1  Information  Flow  Diagram 


There  exists  a trade  between  control  mode  requirements  and  hardware.  The  control  mode 
usually  indicates  direct  measurements  as  the  best  approach,  while  hardware  studies 
indicate  minimizing  measurements  as  being  the  most  reliable  and  cost  effective,  and 
least  risky  to  the  program.  In  several  instances,  it  was  possible  to  eliminate 
measurement  requirements.  For  example,  the  initial  flow  diagram  Indicated  a need 
for  total  pressure  and  temperature  measurements  at  the  entrance  of  the  low  pressure 
compressor.  After  an  Initial  review  of  the  design  requirements  for  the  probes,  it 
was  decided  that  a cost  savings  could  occur  if  an  alternative  measurement  were  used. 

In  this  case,  it  was  possible  to  define  a performance  correlation  that  permitted  use 
of  engine  inlet  pressures  and  temperatures  Instead.  Accuracy  analyses,  including 
engine  to  engine  variations  and  engine  degradation,  wore  very  Important  In  establishing 
parameter  substitution  in  lieu  of  direct  measurements. 


The  environment  to  which  airframe  components  are  exposed  tends  to  be  more  benign  than 
that  on  the  engine.  This  generalization  must  be  evaluated  carefully,  however,  in  the 
case  of  high  performance  aircraft,  where  both  the  temperature  and  vibration  levels  In 
the  inlet  area  may  approach  those  associated  with  the  engine  bay.  The  time  for  which 
the  components  are  exposed  may  be  much  shorter  for  those  units  mounted  in  (or  on)  the 
airframe,  however.  For  example.  Figure  3.4-2  shows  the  temperature  history  of  a 
transducer  that  was  mounted  on  the  cowl  of  the  IPCS  F-111E  test  aircraft.  Since  the 
F-lll  is  capable  of  only  a short  period  of  high-speed  flight,  the  thermal  lay  of  the 
transducer  was  sufficient  to  prevent  over-temperature.  Figure  3.4-2  also  Indirates 
that  it  is  possible  to  calculate  the  thermal  history  of  components  with  reasonable 
accuracy  even  when  the  geometry  and  the  flowfield  are  complicated. 

Passive  protection,  e.g.,  synthetic  foam,  should  be  considered  for  sensors  that 
dissipate  so  little  power  internally  that  self-heating  is  not  a problem.  (See  Section 
6.5.). 
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3.4.2  Controller  Requirements 


The  development  of  controller  requirements  constitutes  a system  engineering  task  that 
will  generate  a detailed  design  specification  for  the  controller.  An  analysis  of  the 
control  algorithms  providesthe  basis  for  specifications  for  the  processor  (computer) 
memory  and  software.  The  number  of  control  loops,  the  number  of  bi -variate  and  uni- 
variate functions,  the  logical  control  switching  functions,  data-bank  sizing,  and 
control  loop  response  times  provide  the  data  required  to  establish  processor  speed, 
instructions  list,  memory  size,  and  configuration  requirements.  These  specifications 
will  become  part  of  the  "Base-line  Propulsion  System  Definition  and  Requirements" 
document. 

L * 

3.4.2. 1 Control  Algorithms  to  be  Implemented 

The  baseline  control  algorithms  defined  in  Section  3.2  will  be  restated  from  the  stand- 
point of  the  controller.  FORTRAN  statements  excerpted  directly  from  the  digital 
simulation  program  may  be  used  to  develop  Functional  Control  System  block  diagrams 
similar  to  Figure  3.4-3  which  was  developed  for  the  IPCS. 
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Functional  Block  Diagram 
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The  diagrams  which  show  the  implementation  of  the  control  algorithms  constitute  an 
expansion  of  the  functional  block  diagrams  to  include  the  actual  controller  hardware/ 
software  which  implement  the  control.  Figure  3.4-4  is  an  example  of  this  type  of 
diagram. 

3. 4. 2. 2 Functional  Description 

The  control  implementation  diagrams  identify  input  conversion  circuitry,  output 
circuitry,  and  software  required.  The  number  of  input  channels,  output  channels,  type 
of  conversions  required  for  both  input  and  output  can  be  determined.  A preliminary 
system  design  can  be  specified  by  block  diagrams. 

Descriptions  should  be  provided  as  listed  below: 

1.  Flight  hardware 

2.  Support  hardware 

3.  System  turn-on/off  flow  diagram 

4.  Input/Output  tables  (transducers  and  actuators  listed) 

5.  All  transducers  and  actuators 

6.  Computer  specifications 

7.  Memory  specifications 

8.  Input  electronics  specifications 

9.  Output  electronics  specifications 

10.  Computer  interface  electronics  specifications 

11.  Power  supply  electronics  specifications 

These  descriptions  should  include  system  level  block  diagrams  and  detailed  electrical 
specifications.  The  specifications  for  the  transducers  and  actuators  should  provide 
actual  detailed  schematics,  if  possible.  It  would  also  be  timely  to  request  actual 
transducer  and  actuator  hardware  specimens  for  laboratory  test  of  the  interface  to 
the  controller  electronics. 

3.4.  23  Environment 

A trade  study  should  be  performed  by  the  intercompany  design  team  to  define  the 
optimum  mounting  of  the  electronics.  This  study  should  address  itself  to  on-engine 
vs  off -engine  mounting. 

The  reliability  of  the  electronics  is  directly  related  to  the  environment  in  which  the 
electronics  must  function;  therefore,  the  cost  of  special  engine  mounted  heat  exchanger, 
vibration  isolation  mounting,  and  other  features  that  will  optimize  the  environment 
must  be  traded  against  a decrement  in  system  reliability.  The  environmental  requirements 
of  the  controller  will  be  based  on  the  result  of  this  study. 

An  early  IPCS  study  performed  by  Honeywell  resulted  in  the  recommendation  that  the 
DPCU  be  mounted  in  the  Weapons  Bay  of  the  F-lll  insteady  of  the  electronics  bay.  This 
decision  generated  the  need  for  a specially  designed  mounting  box  that  provided  a low 
vibration,  well  cooled  environment  and  permitted  shorter  cables  to  the  engine.  The 
benign  environment  resulted  in  very  good  system  reliability. 

Extrapolation  to  future  on-engine  mounting  suggests  the  design  of  an  electronics 
mounting  box  as  an  integral  part  of  the  initial  engine  design.  Table  3.1 -5. "Example 
Requirements  for  the  Electronic  Controller"  provided  suggested  requirements  based  on 
a special  designed  engine  mounted  box  for  the  electronics.  This  subject  is  discussed 
further  in  para  6. 3. 1.1. 

3.4.2. 4 Interfaces 

The  DPCU  interfaces  were  listed  in  the  design  specification  by  tables  and  wire  lists. 

The  early  definition  of  these  wire  lists  was  important  as  it  established  connector/ 
cable  configuration  control,  EMI  characteristics  and  cable  weight  data.  In  addition 
to  the  wiring  interface,  pneumatic  and  hydraulic  interfaces  must  be  defined.  Cooling 
air  (if  used)  must  be  specified,  for  example. 
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3. 4. 2. 5  Installations 
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The  optimum  installation  configuration  depends  completely  upon  the  aircraft  application.  Hence 
the  packaging  and  installation  of  the  electronics  system  must  also  be  treated  by  the  inter- 
company design  team  in  order  to  address  the  questions  of  space,  structural  support,  environment, 
routing  of  wiring  and  plumbing,  and  access  for  maintenance.  A tentative  installation  concept 
must  be  selected  early  in  the  design  cycle  in  order  to  support  mechanical  design  of  the  electronics 
module  and  the  hardware  physically  associated  with  it.  The  installation  concept  must  be 
reviewed  and  adjusted  as  the  system  design  matures. 

3. 4. 2. 6 Software 

Information  documented  in  the  control  algorithms,  the  functional  control  system  diagrams,  the 
implementation  of  control  diagrams,  FORTRAN  statements,  BITE  requirements,  the  I/O  tables,  and 
the  controller  functional  description  is  used  in  the  definition  of  software  design  requirements. 

The  software  design  specification  will  document  requirements  and  information  peculiar  to  the 
design,  development,  performance,  test  and  qualification  of  the  controller  software.  It  can 
also  divide  the  software  development  into  workable  blocks  and  define  requirements  for  each. 

The  IPCS/BOMDIG  programs  were  developed  along  such  a modular  concept.  Computer  Program  Components 
(CPC)  were  established  for  Executive,  Sensor  Processing,  Control,  and  Output  Processing.  A 
computer  program  data  base  was  also  defined. 

The  software  CPC's  are  further  defined  by  inputs  definition,  processing  equations,  and  outputs 
definition  for  each  of  the  subcomponents  of  each  CPC.  Flow  diagrams  should  be  generated  where 
required  to  delineate  the  software  design  further. 

3. 4. 2. 7 Processor  Capabil ity 

Detailed  processor  (computer)  requirements  can  be  established  after  the  work  described  in 
earlier  paragraphs  of  Section  3.4  has  been  accomplished.  A rough  order-of-magni tude  estimate 
of  processor  capability  requirements  may  be  based  on  prior  experience,  but  the  detailed  require- 
ments must  be  left  until  this  stage  of  the  development. 

The  number  of  control  loops,  the  number  of  bi-variate  and  uni-variate  functions,  the  logical 
control  switching  functions,  data-bank  sizing,  control  loop  response  times,  the  number  of 
hardware  input/output  channels  and  type  of  convertors  required;  provide  the  data  required  to 
specify  the  processor:  instruction  repertoire,  speed,  memory  mix,  (i.e.,  between  read-only, 

read-write,  and  volitile  memory)  memory  size,  and  configuration  requirements. 

3. 4. 2. 8 Power  Conditioning 

Sources  of  electrical  power  to  operate  the  computer  and  the  electrical  hardware  associated  with 
the  controller  constitute  a major  design  constraint.  Trade  studies  must  be  conducted  by  the 
intercompany  design  team  to  establish  requirements  for  power  supplies  and  the  driven  components 
(motors,  solenoids,  etc)  concurrently  to  ensure  that  the  system  is  optimized. 

There  are  advantages  to  the  use  of  a power  source  that  is  an  alternator  dedicated  only  to 
propulsion  controls.  The  power  from  such  an  alternator  can  have  relatively  poor  voltage  and 
frequency  tolerance  and  still  be  acceptable.  The  alternator  can,  in  fact,  be  gear  driven  off 
the  engine;  no  constant-speed  drive  is  required.  Electrical  isolation  is  a major  advantage  of 
dedicated  alternator.  This  will  reduce  the  design  requirements  for  tolerance  nuisance  power 
transients.  (See  paragraph  6. 3. 1.2)  An  "essential  bus"  of  well-regulated  uninterrupted  power 
within  the  aircraft  system  would  be  an  attractive  alternative. 
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3. 4. 2. 9 Input/Output 

The  requirements  for  the  input  and  output  electronics  are  directly  related  to  the 
sensors  and  actuators  selected.  Care  must  be  taken  in  the  selection  of  those  devices 
so  they  will  not  complicate  I/O  design  requirements.  Stepping  motors,  vibrating 
crystal  pressure  transducers,  special  33V  dc  devices,  high  power  solenoids,  and  the 
TIGT  sensor  are  examples  of  devices  used  on  IPCS  that  required  a complex  I/O  config- 
uration. These  trades  are  discussed  further  in  paragraph  6.3. 1.9. 

Tolerance  and  timing  requirements  should  be  anlayzed  to  prevent  "over-kill"  designs. 

In  addition,  as  a design  goa1,  control  algorithms  should  be  developed  that  will 
reduce  the  tolerance  requirements  as  far  as  possible.  Liberal  I/O  tolerance 
specifications  will  enhance  system  reliability,  because  circuits  with  fewer  parts 
can  be  used. 

3.4.2.10  Built-In-Test  Equipment  (BITE) 

Both  hardware  BITE  and  software  test  routines  were  used  effectively  on  IPCS.  The 
following  design  methodology  was  used: 

1.  Development  of  a DPCU  start-up/shut-down  flow  diagram 
(Figure  3.4-5). 

2.  Development  of  System  Block  Diagram  with  defined  features 
relating  to  start-up/shut-down  requirements. 

3.  The  development  of  status  and  engage  boolean  equations  after 
preliminary  hardware  and  software  design  was  completed. 

4.  Definition  of  status  and  engage  hardware  requirements. 

5.  Preliminary  Failure  Modes  and  Effect  Analysis  (FMEA)  of 
total  system. 

6.  Inclusion  of  additional  hardware  design  features  based  on 
preliminary  FMEA. 

7.  Development  of  additional  software  test  routines  as  required. 

The  development  of  BITE  requirements  should  follow  the  same  development  procedure. 

The  initial  requirements  should  include  a flow-diagram  similar  to  Figure  3.4-5.  In 
addition,  the  concept  of  BITE  must  be  applied  in  both  hardware  and  software.  DCU 
self-testing  should  provide  99  percent  confidence  that  any  DCU  failure  will  be  detected. 
In  addition,  manual  emergency  shut-down  must  be  provided  as  last  ditch  protection. 

3.4.2.11  Expansion  Options  and  Flexibility  Features 

The  development  of  expansion  option  and  flexibility  requirements  for  a prototype 
system  should  include  certain  features: 


1.  Input  electronics  that  can  write  128  memory  words  through  DMA.  The 
DCU  must  not  be  able  to  write  in  those  128  locations. 

2.  Provide  50%  spare  memory  capability.  Note  that  the  cost  of  core 
is  decreasing  while  the  cost  of  programming  is  increasing.. 

3.  Provide  spare  input  and  output  channels.  Eight  spare  analog 

and  eight  spare  discrete  channels  are  suggested  each  for  the  input 
electronics  and  the  output  electronics. 

i 

3.4.2.12  Signal  Noise 

The  IPCS  experience  with  signal  noise  and  sensor  accuracy  was  deceptively  pleasant. 
Transducers  were  selected  to  meet  conservative  requirements,  electronics  and  cabling 
were  constructed  to  best  possible  practice  in  terms  of  shielding,  grounding  etc.,  and 
computer  capability,  core  and  cycle  time,  were  ample.  Cost  of  these  elements  was  not 
a major  concern. 

In  a production  program  system  cost  considerations  will  force  the  use  of  minimum 
acceptable  equipment  and  difficult  decisions.  The  following  guidelines  are  offered 
based  on  the  IPCS  experience. 
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1.  Analog  processing  circuitry  and  cabling  design  should 
emphasize  noise  suppression  over  cost. 

2.  12  bit  A/D-D/A  converters  are  a good  practical  compromise 
between  cost  and  utility. 

3.  When  using  digital  or  AC  sensors  beware  of  beat  frequency 
or  carrier  frequency  aliasing  and  sampling  effects. 

4.  Noise  sensitivity  of  control  algorithms  should  be  emphasized  as 
a trade  parameter  in  selecting  control  algorithms. 

IPCS  experience  confirms  that  good  design  practices  result  in  a quiet  system.  These 
include: 

1.  Single  point  ground, 

2.  Twisted  pair  wiring  for  noise  reduction, 

3.  Isolate  digital  and  analog  signals  in  wiring  harnesses, 

4.  Use  both  low  frequency  and  RF  shields, 

5.  Careful  attention  to  high  frequency  effects  in  electronics 
box  grounding  system  design. 

High  frequency  noise  and  aliasing  in  the  analog  sampling  process  are  avoided  by  low  pass 
filters  on  the  input  side  of  the  multiplexer.  Selection  of  these  filters  is  based  on 
system  characteristics  - design  sample  rate,  available  sensor  performance  and  controller 
sample  rate.  A first  order  lag  witn  a 16  Hz  corner  provided  acceptable  results  for  IPCS. 


The  N1 , N2,  and  T4  sensors  exhibited  excessive  noise  levels  during  the  IPCS  program. 

The  N1  and  N2  noise  were  eliminated  by  increasing  the  sample  rate  to  obtain  a 
sampling  duty  cycle,  defined  as  number  of  events  sampled/total  samples  generated,  of 
70%.  Initially  this  was  thought  of  as  a simple  averaging  approach  to  minimizing 
random  noise.  After  data  reduction  it  is  evident  that  the  relatively  low  original 
sampling  duty  cycle,  11%,  created  a potential  aliasing  situation  and  tachometer 
characterises  and/or  gear  train  resonance  were  of  a frequency  to  be  mapped  into 
the  low  frequency  control  range. 

3.5  RELIABILITY  REQUIREMENTS 

3.5.1  Purpose  and  Scope 

The  reliability  methodology  discussed  here  has  been  derived  from  the  experience 
accumulated  during  the  IPCS  program  and  a post-program  assessment  of  significant 
aspects.  The  basic  IPCS  reliability  program  ended  at  the  final  design  review,  the 
failure  reporting  program  continued  throughout  the  test  program,  however.  Sufficient 
time  has  elapsed  to  employ  some  of  the  IPCS  techniques  on  other  programs.  On  these 
programs  the  IPCS  methods  proved  effective.  In  other  cases  the  rationale  used  to 
conduct  certain  activities  proved  useful  and  eliminated  the  proverbial  "starting 
from  scratch". 

It  was  assumed  that  the  future  program  is  sufficiently  similar  to  the  IPCS  program  that 
the  reliability  methodology  can  be  applied  directly. 

The  discussion  of  reliability  methodology  covers  two  areas:  (1)  program  control  requirements 

such  as  developing  a program  plan,  establishing  a r rts  selection  and  control  program, 
subcontractor  control  and  failure  reporting,  anal;  i and  corrective  action,  and  '(2)  analysis 
requirements  such  as  numerical  estimates  of  system  reliability  and  FMEA’s. 

The  specific  goal  of  the  IPCS  reliability  program  was  to  preclude  three  different 
approaches  to  each  reliability  task.  With  the  combined  reliability  experience  of  the 
three  contractors,  it  was  demonstrated  to  be  possible  to  formulate  one,  consistent 
approach  to  meet  the  program  requirements.  If  a future  program  were  to  involve  sub- 
contractors with  less  reliability  experience  than  the  IPCS  team,  it  may  be  beneficial 
to  tailor  the  reliability  program  for  the  subcontractor  and  dictate  specific  approaches 
and  methods. 


3.5.2  Reliabil ity  Tasks 

This  section  deals  with  the  requirements  appropriate  to  the  design,  development  and  test  of  an 
integrated  propulsion  control  system  and  the  rationale  used  to  develop  the  methods  and  procedures 
to  carry  out  the  required  tasks. 

3.5.2. 1 Reliability  Program  Plan 

The  IPCS  statement  of  work  specified  each  reliability  task  or  requirement.  These  tasks  form 
the  basis  of  the  traditional  reliability  specification  MIL-STD-785A.  The  unique  aspect  of  the 
IPCS  statement  of  work  was  that  the  methods  of  accomplishing  the  tasks,  usually  spelled  out  in 
great  detail  in  the  MIL-STD,  were  left  to  prime  contractor  to  define.  There  are  good  reasons 
for  this  approach: 

1.  The  TPCS  program  was  an  exploratory  development  program  and 
Government  was  aware  of  the  possible  need  to  develop  unique 
approaches  to  satisfy  the  requirements  within  the  time  and 
cost  constraints  of  the  program. 

2.  MIL-STD-785A  methods  can  be  quite  costly  and  are  justified 
for  large  programs  of  long  duration  where  both  hardware  and 
data  management  problems  are  well  defined. 

The  IPCS  reliability  program  developed  by  each  contractor  presented  a brief  statement  of  each 
task  to  be  performed,  the  organization  responsible  for  that  task,  the  methods  to  be  used,  and 
the  schedule  for  each  task  output. 

3. 5. 2. 2 Subcontractor  Control 

Subcontractors'  interpretations  of  MIL-STD-785A  can  vary.  On  IPCS  it  was  the  responsibility  of 
the  Prime  Contractor  to  bring  these  differing,  but  not  necessarily  conflicting,  approaches 
together  to  accomplish  the  reliability  requirements  of  the  program.  This  was  accomplished 
through  the  Reliability  Program  Plan,  approved  by  the  Prime  Contractor  and  through  person-to- 
person  contact  within  the  various  engineering  special istics. 

3. 5. 2. 3 In-House  Reliability  Program  Requirements 

Most  large  corporations  have  Policy  Statements  addressing  Reliability.  The  Reliability  Manager 
is  required  to  define  project  reliability  requirements  for  each  new  program  which  reflect  the 
contractual  aspects  of  the  Program  and  identify  the  working  relationships  between  Design, 
Reliability  and  related  organizations.  These  documents  serve  to  guide  the  in-house  activities 
relating  to  satisfying  the  Program  reliability  requirements.  On  an  experimental  program,  only 
a minimum  number  of  in-house  procedures  are  necessary  to  accomplish  the  required  tasks.  The 
rationale  for  developing  in-house  operating  procedures  is  to  ensure  that  reliability  gets  the 
support  needed  to  accomplish  the  required  tasks;  no  more  - no  less. 

3. 5. 2. 4 Parts  Program 

One  of  the  most  important  aspects  of  a new  development  program  is  the  policy  on  Parts  Selection 
and  Control.  On  IPCS,  the  Program  Plan  clearly  defined  part  quality  levels  and  derating 
requirements.  The  selection  of  parts  served  to  establish  for  the  Subcontractors  the  reliability 
philosophy  for  their  programs.  The  rationale  for  including  the  parts  program  in  the  reliability 
plan  was  to  avoid  producing  a separate  document  which  is  costly  and,  more  importantly  to  keep 
this  significant  item  in  the  reliability  document  itself.  MIL-STD-749B  provided  the  mechanism 
for  justifying  the  usage  of  non-standard  parts  (NSPs),  i.e.,  parts  not  on  the  preferred  parts 
list,  since  many  circumstances  can  preclude  the  use  of  preferred  parts. 

The  philosophy  clearly  specified  in  the  IPCS  Statement  of  Work  required  that  ER  (Established 
Reliability)  level  parts  be  used.  With  the  parts  quality  spelled  out,  IPCS  developed  a straight 
forward  parts  program  listing  every  part  type  and  its  corresponding  MIL-SPEC.  Parts  not 
available  from  the  IPCS  parts  list  were  used  and  justified  per  MIL-STD-749B.  The  customer  was 
provided  with  every  NSP  written  on  the  program  to  provide  visibility  on  the  non-standard  parts 
that  were  used. 
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3 -5.2.5  Failure  Mode  and  Effects  Analysis  (FMEA) 
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MIL-STD-785A  requires  a Failure  Mode  and  Effects  Analysis.  This  analysis  can  be  a very 
powerful  and  useful  study  since  on  a small  program  all  possible  failures  can  be  examined 
and  traced  through  the  system  to  establish  the  effects  on  the  system  during  various 
phases  of  the  mission.  This  analysis  serves  better  to  identify  design  problems  than  a 
numerical  prediction,  as  it  requires  the  designers  to  examine  the  system  end-to-end 
without  being  concerned  about  the  probability  of  occurrence.  If  a failure  mode  is 
deemed  critical,  the  reliability  analyst  can  then  assign  a probability  value  or  failure 
rate  to  prioritize  the  failure  modes  and  provide  Management  with  a guide  for  a redesign 
strategy,  if  necessary.  Particular  emphasis  was  placed  on  examining  failure  mode 
effects  at  interface  points,  e.g.,  where  Honeywell's  IFU  interfaced  with  P&WA 
actuators.  Each  IPCS  contractor  performed  the  FMEA  on  their  own  hardware  and  traced  the 
effects  of  the  failure  through  the  system  and  assessed  the  criticality  of  each.  Interface 
failure  modes  were  cross-checked  to  determine  the  effect  of  failure  modes  on  the  system 
and  each  contractor's  hardware.  In  this  way  a countercheck  was  made  possible  on  the 
failure  effects  at  the  system  level. 

One  of  the  benefits  of  the  FMEA  is  the  identification  of  backup  modes  of  operation 
required  in  the  event  a primary  unit  fails.  Backup  modes  include  the  use  of  redundant 
or  alternative  combinations  of  hardware  or  software  to  accomplish  the  same  function. 

3-5. 2. 6 Numerical  Rel iability  Requirements 

Numerical  requirements,  in  terms  of  an  MTBF  or  Probability  of  Success  are  imposed  on 
most  military  program,  although  this  was  not  the  case  for  IPCS.  The  requirements 
can  take  either  of  two  forms: 

1.  A minimum  acceptable  value  (to  be  demonstrated  by  analysis 
or  test) 

2.  A goal  (failure  to  meet  the  goal  would  not  incur  penalty) 

The  requirement  establishes  reliability  as  a performance  criterion  that  will  be  given 
the  same  level  of  consideration  in  design  as  any  other  parameter  so  that  the  concepts  under 
evaluation  will  not  be  compromised  with  respect  to  the  reliability  requirements. 

In  the  case  of  IPCS  the  goal  was  not  only  to  advance  the  state-of-the-art  relative 
to  digital  computer  control  of  an  aircraft  propulsion  system  but  also  to  ensure  the  safety 
of  the  flight  crew.  In  fact,  since  reliability  is  an  important  consideration  in  the 
acceptability  of  electronic  digital  controls,  reliability  became  an  objective  in  itself. 

It  is  important  that  the  appropriate  model  representing  the  failure  probability 
distribution  of  the  system  under  analysis  be  selected.  Only  good  judgement  and  experience 
with  similar  systems  can  provide  the  basis  for  choosing  the  proper  mathematical  model. 

3. 5. 2. 7 Failure  Reporting,  Analysis>and  Corrective  Action 

MIL-STD-785A  requires  an  extensive  effort  for  failure  reporting,  analysis,  and 
corrective  action.  These  requirements  are  absolutely  necessary  on  a large  program 
in  order  to  accumulate  failure  data  and  to  document  corrective  action.  The  failure 
reporting  system  requires  a single  report  immediately  following  the  failure,  followed 
by  an  analysis  and  corrective  action  report  approved  by  Reliability  and  the  Program 
Manager. 

3. 5. 2. 8 Design  Reviews  and  Coordination  Meetings 

Separate  design  reviews  were  held  during  the  IPCS  program  for  each  contractor.  At  these 
reviews  the  reliability  prediction,  FMEA  and  parts  program  tasks  were  discussed. 

Since  the  ground  rules  were  previously  established,  the  Government  presentations  were 
always  consistent:  At  each  review  Boeing  presented  an  overview  of  the  total  IPCS 

reliability  program.  The  intention  there  was  to  avoid  a fragmented  reliability  story 
throughout  the  program. 
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3,5. 2. 9 Project  Organization 

On  IPCS,  the  three  contractor  reliability  groups  reported  directly  to  their  respective 
Program  Managers.  This  is  generally  not  the  case  on  large  programs.  The  major  benefits 
of  this  approach  are: 

1.  The  program  manager  is  constantly  aware  of  the  status  of  the 
reliability  program. 

2.  Reliability  can  get  immediate  resolution  of  problems  within 
his  own  organization  or  between  the  subcontractors. 

3.  The  program  manager  has  the  reliability  group  at  his  disposal 
to  work  special  problems  without  adding  to  the  work  load  of 
the  Design  Manager. 

3.5.3  Assessment  of  the  IpCS  Reliability  Program 

As  indicated  in  Section  3.5.1,  enough  time  has  elapsed  since  completion  of  the  IPCS 
reliability  program  to  “stand-back"  and  evaluate  the  merits  or  shortcomings  of  the 
approaches  taken  Table  3.5-1  summarizes  the  results  of  this  evaluation. 

The  IPCS  FMEA  approacn  was  recently  used  on  the  Boeing  Compass  Cope  program  with  much 
success.  A parts  control  problem  was  experienced  on  a subsequent  program  because 
procedures  similar  to  those  used  on  IPCS  were  not  followed. 

3.5.4  Engine  Reliability  Requirements 

Reliability  requirements  for  propulsion  system  control  are  determined  by  the  require- 
ments established  for  the  overall  "weapons  system"  by  the  customer.  The  system 
integrator  establishes  a numerical  reliability  "budget"  value  or  target  for  the 
propulsion  system  which  when  factored  together  with  other  airplane  system  will  meet 
the  customer  requirements.  The  propulsion  system  reliability  budget  is  divided 
between  the  various  major  components  of  the  system  to  permit  definition  of  the 
requirements  imposed  upon  the  propulsion  control  system. 

Reasonable  numerical  reliability  requirements  should  be  established  by  the  system 
integrator  early  in  the  design  process,  so  that  the  requirements  could  be  met  as  far 
as  possible  by  using  off-the-shelf  components  and  state-of-the-art  design  procedures. 

The  key  to  success  of  a reliability  design  is  to  provide  a contractor  environment  where 
there  is  free  and  continual  communication  between  the  working-level  reliability  personnel 
of  the  participating  contractors  throughout  the  program.  This  not  only  provides  the 
basis  for  exchange  of  the  best  infromation  requirem  but  permits  a timely  resolution  of 
problem  areas.  Good  documentation  of  all  decisions  relating  to  reliability  is  essential. 
The  documentation  should  be  in  two  levels.  One  would  be  a formal  exchange  of  information 
between  contractors  using  the  coordination  memo  system.  The  other  would  be  a less  formal 
meeting  between  working  level  engineers  at  each  contractors  site  to  permit  early 
identification  of  the  reliability  impact  on  the  various  components  being  designed. 

In  summary,  successful  reliability  functioning  requires  a program  management  decision 
to  permit  the  flexibility  required  to  do  the  job  at  a level  wherein  reliability 
personnel  of  each  contractor  get  to  know  each  other  and  work  together  to  arrive  at  a 
point  where  the  overall  system  reliability  budget  is  not  exceeded. 

3.5.5  Electronic  Reliability  Requirements 

It  is  important  that  an  electronics  specialist  be  involved  in  the  initial  engine 
development.  This  involvement  is  necessary  so  that  the  mechanical,  thermal,  and 
electrical  interfaces  can  be  optimized  to  provide  a reliable  controller. 

Reliability  is  obtained  through  the  application  of  all  of  the  following  basic 
considerations : 


52 


TASK 

Rel lability 
Program  Plan 


Table  3.5-1  IPCS  Reliability  Proqram  Assessment 
I PCS  APPROACH 

PRO  CON 


Subcontractor 

Control 


Revised  document 
after  coordination 
meetinq  defined 
parts  control 
orogram,  FMFA, 
predicted  ground- 
rules  and  failure 
reporting  pro- 
cedures 


The  close  working 
relationships 
established  early 
in  the  program 
were  the  key  to 
meeting  all 
rel iabil ity 
objectives 


Initial  document  too 
vague,  schedules  not 
per  contract,  CDRt 
items  not  recognized/ 
addressed  properly 


Prediction 


Failure  Modes 
and  Effects 
Analysis 
( FMEA ) 


All  ground  rules 
agreed  upon  by 
the  three 
contractors,  all 
data  sources  were 
identified  mathe- 
matical reliabil- 
ity function  was 
agreed  upon. 

The  three  cont- 
racts were 
experienced  in 
FMEA's  and 
adopting  common 
groundrules  was 
no  problem. 


Software  reliability 
was  included  in  the 
system  reliability 
model  but  not 
adequately  addressed 
due  to  lack  of  data 


Due  to  the  time 
constraints  of  the 
program  it  was  not 
possible  to  go 
"inside"  the  DPCU. 
Only  the  outputs  of 
the  DCU,  IFU  were 
examined. 


Parts  Program 

Part  quality 

Non-standard  part 

levels  were  a 

justification  data 

agreed  on. 

was  not  as  complete 

derating  criteria 

as  expected  but  did 

(although  diff- 

meet the  intent  of 

erent  within  each 
company)  were 
tailored  to  common 
levels;  Non- 
standard part 
criteria  were 
established 

MIL-STD-749B 

Failure 

A simplified 

In  some  cases. 

Reporting, 

approach  was 

simplicity  led 

Analysis  and 

adopted,  In 

to  complacency. 

Corrective 

contrast  to 

not  deliberately 

Action 

M1L-STD-785A 

but  due  to  schedule 

but  was  adequate 

and  other  problems 

. 

for  IPCS 

failure  reporting 
was  sometimes  "not 
per  spec." 

i 

Program 

Reliability 

Management 

reported 
directly  to  the 
Program  Manager 

SUCCESS  ASSESSMENT 

Based  on  past  experience  the 
prime  contractor  should  have 
been  more  specific  at  the  outset 
of  the  program.  The  resultant 
coordination  meeting  however  was 
the  key  toward  establishing  the 
requirements  and  working  relation- 
ships among  the  three  contractors 
on  IPCS  which  carried  through  the 
entire  contract. 

The  success  of  any  program,  large 
or  small,  depends  on  the  cooper- 
ation of  all  concerned.  The 
IPCS  approach  of  unrestricted 
communication  among  the  design 
and  reliability  engineers  was  an 
extremely  successful  approach. 

This  represented  a departure 
from  the  usual  approach  of  n- 
levels  of  management  approval 
of  what  is  going  on  at  the 
working  level. 

The  prediction  effort  went 
smoothly,  compared  to  other 
programs,  because  data  was 
available  on  the  DPCU  and 
engine  components. 


The  FMEA  was  the  most  significant 
reliability  accomplishment  of 
the  reliability  program.  The 
interfaces  among/between  the 
three  contractors'  hardware  were 
thoroughly  examined.  In  contrast 
to  a prediction  where  there  are 
known  variations  in  failure  rates, 
the  FMEA  identifies  and 
qualitatively  assesses  the 
criticality  of  every  failure 
mode.  The  results  provided 
each  contractor  and  the  Safety 
Board  with  the  engineering 
confidence  that  the  TPCS  system 
was  reliable  and  safe. 

Documentation  requirements  for 
NSP's  per  MIL-STD-749B  can  be 
satisfied  by  joint  Government/ 
Contractor  agreement  to  minimize 
the  paper-flow  thereby  reducing 
cost.  Specification  of  part 
quality  level  early  In  the 
program  and  Identification  of 
the  specific  part  specifications 
applicable  to  the  program  Includes 
later  misunderstanding.  This 
approach  was  very  successful  on 
IPCS. 

This  simplified  approach  seems 
to  provide  as  much  data  as  a 
large  data  collection  program. 

On  larqe  programs  the  amount 
of  failure  data  requires  more 
formalized  procedures  for 
processing,  such  as  computer 
print-outs,  monthly  reports,  etc. 
On  IPCS  and  smaller  programs  of 
short  (3-4  yrs)  duration  a 
failure  reporting  system  similar 
to  IPCS  Is  quite  adequate. 

This  was  a highly  successful 
approach  since  Reliability  had 
direct  access  to  the  Program 
Manager  at  all  times.  On  larger 
programs  Reliability  Is  often 
times  part  of  Systems  Engineer- 
ing without  dl rect  access  to 
the  Program  Manager. 
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1. 


2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 
11. 
12. 


System  Configuration  - The  application  of  the  following  as 
appropriate:  Backup  control,  dual  channel  redundent,  triple 

channel  redundant,  crossfeed,  BITE  (Hardware  and  Software), 
DCU  Self-test,  asynchronous  I/O  channels  with  synchronous 
BITE  and  crossfeed,  redundancy  of  sensors  and  actuators. 
Selection  of  Reliable  Component 
Component  De-Rating 
Conservative  Design 
Low-Risk  Packaging 

Design  for  Relief  of  Environmental  Requirements 
Quality  Control  Inspections 

Temperature-Cycling  of  Complete  Operating  System 
Acquire  adequate  operationaltime  on  the  complete  operating 
system  to  eliminate  infant  mortality  prior  to  shipment 
Vibration  of  complete  operational  system 
All-inclusive  testing 
Pride  in  workmanship 


Items  2 through  12  of  this  list  are  obvious  and  were  applied  in  the  development,  design, 
fabrication,  and  testing  of  the  Honeywell  DPCU.  Item  1,  however,  provides  an  additional 
possibility  for  greatly  increasing  the  reliability  of  the  controller.  The  use  of 
crossfed  redundant  channels  and  conventional  airborne  electronic  environment  can 
provide  reliability  numbers  greater  than  30,000  hours  for  a flight  control  system. 
Assuming  that  a flight  control  system  has  complexity  equivalent  to  an  engine  control 
system,  it  is  feasible  to  configure  a system  with  like  reliability. 

3.6  QUALITY  ASSURANCE  PROGRAM  PLANNING 


Assignment  of  a Q.A.  specialist  will  occur  during  contract  definition  and  approximately 
60  days  before  proposal  submittal.  His  assignment  during  this  period  will  include 
participation  in  initial  planning  with  other  functional  groups,  i.e.,  Engineering, 
Manufacturing,  Materiel,  etc.  Development  of  a basic  quality  approach  will  be 
initiated  and  become  a part  of  the  proposal.  This  will  include  a general  description  of 
the  Company's  Quality  organization  and  system  plus  a planned  approach  for  performing  the 
desired  degree  of  quality  inspections,  surveillances  and  documentation  required.  For 
the  proposal  effort,  this  information  will  be  generated  against  known  or  recommended 
planned  tasks  and  schedules.  The  Quality  proposal  will  define  quality  tasks  during  the 
design  effort,  manufacturing,  procurements,  testing  and  integration.  For  example, 
during  a specification  test  operation.  Quality  support  or  participation  will  be 
recommended  and  correlated  to  the  test  schedule. 


In  this  manner,  an  estimate  of  the  required  Quality  resources  and  manpower  can  be 
established  and  made  a part  of  the  proposal.  An  estimate  of  this  nature  can  be 
established  for  each  known  task  including  a definition  of  the  personnel  qualifications 
required  for  completing  the  task.  The  manloading  can  be  time-phased  against  the 
proposed  schedules.  It  must  be  recognized  that  the  initial  proposal  effort  is 
preliminary  and  will  require  expanding  or  updating  as  program  requirements  become  more 
definitive. 

The  Q.A.  specialist's  effort  during  this  contract  definition  phase  may  be  a full-time 
assignment  or  part-time  depending  on  the  scope  of  the  work  to  be  accomplished  and  on 
the  budget  allocated  for  the  effort. 
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4.0  CONTROL  MODE  DESIGN 

Control  mode  design  bridges  the  gap  between  the  conceptual  design  developed  per  paragraph 
3.3  and  the  detailed  definition  of  control  modes  required  for  physical  implementation  of 
the  system.  The  following  results  are  achieved  in  the  process. 

Confirmation  of  the  baseline  control  algorithm 

Development  of  logic  networks 

Selection  of  gains,  setpoints,  and  compensation 

Corroboration  of  component  accuracy  and  frequency  response  requirements 
defined  per  paragraph  3.3 

Development  of  failure  detection  and  back-up  modes  to  meet  reliability 
requirements  of  paragraph  3.5. 

The  paragraphs  below  discuss  the  analytical  tools  used  for  control  mode  design  - computer 
simulation,  classical  linear  analysis,  and  optimal  control  theory.  Special  emphasis  is 
given  to  the  use  of  computer  simulation  because  of  the  role  it  can  also  play  in  hardware 
and  software  testing  ana  in  making  the  transition  from  subsystem  to  system-level  testing. 

Some  of  the  options  available  for  failure  detection  and  back-up  modes  are  discussed  in 
light  of  IPCS  experience. 

4.1  THE  ANALYTICAL  DESIGN  TEAM 


The  propulsion  control  mode  design  process  starts  with  a Preliminary  Design  Phase  using 
the  conceptual  mode  design  developed  during  the  requirements  definition  phase  and  continues 
through  system  development,  frequently  into  the  early  deployment  of  the  flight  system. 

An  Analytical  Design  Team  should  be  formed  early  in  the  process  and  consist  of  members 
from  each  contractor.  The  team  should  include  airframe,  engine,  and  control  manufacturer 
personnel  familiar,  not  only  with  control  system  operations,  but  also  with  their  respective 
plant  requirements,  operating  characteristics,  and  design  processes.  Some  members  should 
be  identified  early  in  the  design  process  as  responsible  for  test  design  and  support  in 
order  to  achieve  continuity  between  the  design  and  test  process.  The  design  team  would 
work  through  a series  of  joint  design  sessions  to  arrive  at  a Mode  Design. 

After  delivery  of  hardware  and  software,  the  design  team  would  support  the  test  program  as 
required  to  ensure  that  satisfactory  control  operation  is  achieved;  essentially  continuous 
support  should  be  provided  at  the  test  site. 

Figure  2.2-2  shows  the  preliminary  design  phase  work  breakdown  schedule  used  in  the 
IPCS  program  to  identify  the  division  of  responsibility,  the  joint  design  sessions,  and 
document  exchanges. 

The  first  period  should  be  used  by  each  contractor  in  preparation  for  the  First  Joint 
Contractor  Analytical  Design  Session.  The  responsibilities  of  each  contractor  at  the 
first  meeting  would  be  to: 


1.  Describe  their  propulsion  system  components  . 

2.  Review  their  analytical  capabilities  and  computer  facilities- 

3.  Identify  requirements  and  design  criteria. 

4.  Summarize  design  progress  to  date,  and  lastly,  but  certainly  not  least, 

5.  Introduce  team  members  from  each  contractor  to  each  other. 


The  goals  listed  below  should  be  pursued  at  the  first  meeting: 


1.  Establish  meeting  objectives 

2.  Agree  on  system  requirements 

3.  Determine  analytical  procedures 

4.  Define  contractor  assignments 

5.  Agree  on  a schedule  for  making  decisions 

6.  Brainstorm  ideas 

7.  Exchange  technical  material 

8.  Establish  ground  rules,  priorities,  and  success  criteria. 


Each  meeting  should  conclude  with  a list  of  action  items  and  due  dates  for  each 
contractor  responsibility. 
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The  first  meeting  would  probably  set  the  pattern  for  the  remaining  meetings.  The  total  number 
of  joint  desinn  sessions  would  be  agreed  upon  at  the  first  session  for  the  preliminary  design 
phase.  Each  session  would  follow  a procedure  that  involves  reviewing  the  work  performed, 
establishing  approaches,  setting  priorities,  and  establishing  work  assignments.  The  duration  of 
the  design  sessions  could  be  two  weeks  or  two  days  depending  uoon  the  task  at  hand.  The  first 
session  would  be  the  most  important  and  most  difficult  one,  since  it  is  here  that  the  actual 
program  participants  establish  requirements  and  design  approaches. 

In  the  IPCS  program  the  “joint  session"  design  approach  worked  well,  providing  a means  for 
communication  which  was  considered  a very  important  part  of  the  design  process,  that  resulted 
in  maximum  coverage  of  all  problems  identified  by  the  various  contractors.  The  general 
procedure  for  obtaining  a mode  configuration  was  for  one  contractor  to  present  an  approach  to 
satisfy  requirements,  and  for  the  other  contractors  working  to  critique.  The  result  was  a 
committee  refinement  of  a particular  design  which  was  then  committed  to  simulation  for  demonstration. 
This  approach  was  very  effective  with  many  decisions  made  by  the  committee.  In  the  event  the 
analytical  team  could  not  arrive  at  a decision  the  alternatives  were  presented  to  the  program 
managers. 

The  assignment  of  action  items  was  made  on  the  basis  of  which  contractor  had  the  facilities, 
resources,  and  experience  to  do  a particular  job.  In  some  cases  assignments  were  made  on  a 
personal  basis  rather  than  on  a contractor  basis  due  to  the  familiarity  each  contractor  had 
with  each  others  team  members.  This  resulted  in  the  most  qualified  contractor  personnel 
assigned  to  perform  particular  tasks. 

Each  contractor  on  the  IPCS  program  identified  a "lead  engineer"  early  in  the  design  process. 

The  lead  engineer  was  responsible  for  the  contractor's  contribution  to  the  mode  design.  It 
would  be  advisable  for  the  lead  engineer  to  remain  on  the  program  through  the  test  phase 
wherein  his  tasks  would  involve  coordination  and  mode  design  changes.  He  would-be  responsible 
for  maintaining  a consistent  level  of  design  contribution  and  interfacing  with  the  other 
contractors.  He  would  also  serve  to  screen  communications  to  avoid  confusion. 

4.2  ANALYTICAL  TOOLS 

There  are  three  fundamental  tools  available  to  support  the  intuition  and  judgement  of  the 
controls  engineer;  simulations,  classical  stability  models , and  optimal  control  theory.  The 
first  two  were  used  extensively  on  the  IPCS  program.  Optimal  control  is  discussed  because  it 
was  explored  briefly  on  the  IPCS  program  and  because  it  is  may  be  relevant  to  future  programs. 

The  material  presented  in  this  Section  is  discussed  in  substantial  detail  because  the  field  is 
developing  so  rapidly  that  standardized,  generally  accepted,  techniques  have  not  yet  evolved. 

Hence  management  guidance  may  be  required  in  organizing  the  analytical  tasks. 

Dynamic  simulations  of  the  F-lll  propulsion  system  formed  the  foundation  for  the  IPCS  control 
system  development  and  software  validation.  Two  types  of  simulations  were  generated.  The 
first  was  an  entirely  digital  simulation  developed  for  a large  digital  computer  such  as  a CDC 
6600.  The  second  was  a comprehensive  hybrid  simulation,  based  upon  the  digital  simulation  that 
was  developed  by  Honeywell.  The  following  paragraphs  describe  the  simulations  used  in  the  IPCS 
program  and  make  recommendations  for  future  applications. 

4.2.1  Digital  Simulation 

The  IPCS  digital  simulation  incorporated  most  of  the  system  definition  data  that  were  available, 
thus  forming  a convenient  repository  for  masses  of  detailed  information.  Linear  state  models 
extracted  from  the  digital  simulation  were  used  to  study  control  system  stability  and  response. 

The  digital  simulation  was  the  principal  test  bed  for  evaluating  new  control  modes. 

A good  digital  simulation  satisfies  three  requirements: 

1.  It  is  a comprehensive  source  of  standard  information  on  the 
steady-state  and  dynamic  characteristics  of  the  plant  to  be 
controlled. 


2.  It  is  a basis  for  analytical  stability  models. 

3.  It  is  a test  bed  for  evaluating  candidate  control  features. 
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The  digital  transient  propulsion  system  simulation  is  used  for  early  control  design  checkout, 
mode  evaluation,  gain  and  compensation  selection,  and  schedule  generation.  It  is  used  in 
later  development  stages  to  help  interpret  test  results  and  investigate  new  development 
problems.  The  extent  to  which  it  serves  these  purposes  is  dependent  upon  its  detail, 
accuracy  and  frequency  response.  To  satisfy  these  usage  requirements  the  propulsion 
system  digital  simulation  should  model  the  following  subsystems: 

1.  Engine 

2.  Inlet  and  relevant  portions  of  the  airframe 

3.  Control  system 

4.  Sensors 

5.  Actuators 

In  addition  the  simulation  should  make  provision  for,  or  include  simple  aircraft 

dynamic  models  to  permit  studies  of  flight  control  related  loops  - for  example  autothrottle, 

buzz  suppression,  CCV/HIMAT/VTOL  flight  control  systems  and  inlet  distortion  control. 

The  heart  of  the  system  simulation  is  the  engine  simulation  discussed  in  paragraph  4. 2. 1.1 
below.  Successful  system  development  requires  integration  of  the  engine  simulation  with 
controller,  inlet,  sensor  and  actuator  simulations.  The  problems  and  potential 
solutions  associated  with  this  integration  activity  are  disucssed  in  Section  4. 2. 1.2. 

4. 2. 1.1  Digital  Engine  Simulation 

The  digital  engine  simulation  used  for  IPCS  and  for  foreseeable  engine  development  programs 
is  a transient  engine  simulation  consistent  with  the  requirements  of  ARP  1257,  with  good 
fidelity  for  frequencies  less  than  30  Hz. 

The  initial  digital  simulation  will  be  based  on  predicted  engine  performance  and 
component  characteristics.  As  component  rig  tests  provide  better  definitions  of 
component  characteristics , the  simulation  should  be  updated  to  reflect  these  results. 

This  primarily  involves  refitting  compressor  and  turbine  maps  from  their  early  estimates 
to  their  demonstrated  performance  levels.  Variable  geometry  and  bleed  effects  on 
compressor  speed-flow,  efficiency,  and  surge  line  should  be  included  in  the  simulation 
as  appropriate.  Engine  match  changes  resulting  from  the  component  testing  should  also 
be  included  in  the  simulation. 

The  simulation  should  eventually  predict  accuractly  engine  response  to  changes  in  all 
controllable  parameters.  These  include  fuel  flow,  compressor  variable  geometry, 
compressor  bleeds,  compressor  face  conditions,  variable  turbine  area,  afterburner  fuel 
flow  and  variable  exhaust  nozzle  area.  It  should  also  predict  engine  response  over 
the  entire  flight  envelope  (altitude,  Mach  number),  was  well  as  other  influences  such 
as  service  bleed,  horsepower  extraction,  and  heat  transfer  effects.  The  effects  of 
most  of  these  factors  are  usually  known  with  sufficient  accuracy  early  in  the  development 
process  to  facilitate  control  studies.  The  incorporation  of  bleed  valve  dynamics, 
actuator  dynamics,  and  sensor  response  characteristics  further  enhances  the  usefulness 
of  the  simulation,  providing  refinements  to  the  engine  response  predictions  that  permit 
more  accurate  assessment  of  control  gains,  compensations,  and  hysteresis. 


As  development  progresses  to  engine  test,  component  interaction  effects  are  Identified, 
and  the  simulation  must  be  adjusted  accordingly.  Interaction  effects  can  be  simulated 
by  variable  scaling  of  the  compressor  and  turbine  speed-flow  and  efficiency  characteristics. 
Engine  test  data  also  provide  the  first  check  on  the  simulation  predictions  for  transient 
operation.  Heat  transfer  effects,  rotor  inertias,  and  volume  distribution  can  be 
evaluated  by  inputting  the  fuel  flow  trace  measured  during  the  transient  and  comparing 
predicted  engine  response  with  the  measured  response.  Alternatively  a programmable 
digital  controller  can  automatically  generate  engine  step  responses  to  input  variables. 

Although  the  IPCS  program  began  with  a fully  developed  engine,  the  transient  simulation 
evolved  in  three  phases.  The  first  phase  was  a SMITE  simulation  which  was  developed  prior 
to  IPCS  conception  and  was  used  for  early  studies.  The  second  phase  was  conversion  to 
the  SOAPP  (State-of-the-Art  Performance  Program)  system  to  Improve  simulation  flexibility 
and  facilitate  link-up  with  the  F-lll  inlet  model.  Component  maps  were  also  updated 
during  this  conversion  to  provide  better  agreement  with  the  sea  level  static  production 
engine  data.  The  third  phase  consisted  of  fine  tuning  component  maps  to  match  altitude 
performance  demonstrated  by  one  of  the  engines  assigned  to  the  IPCS  program.  A comparison 
of  the  initial  and  final  simulation  predictions  with  engine  test  data  is  shown  in  Figures 
4.2-1  and  4.2-2. 
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Estimated  Engine  Performance  Figure  4.2-2  Comparison  of  Baseline  Enaine  Data  to  Enoine  Simulation 


Though  continual  simulation  refinements  will  ultimately  lead  to  predictions  that  are  ever 
closer  to  measured  data,  there  is  a trade  between  the  development  effort  required  to 
achieve  high  accuracy  and  the  benefits  accrued  therefrom.  If  a programmable  controller 
is  used  during  early  engine  development  testing,  simulation  accuracy  becomes  less 
critical  because  gains,  compensations,  and  schedules  can  be  easily  modified.  If  this 
control  flexibility  is  not  available  during  early  engine  development,  then  simulation 
accuracy  becomes  more  important  in  minimizing  the  number  of  changes  required.  In  addition, 
good  simulation  accuracy  in  predicting  engine  operation  around  the  flight  envelope  can 
minimize  surprises  during  initial  flight  testing.  The  TF30-P-9  engine  simulation 
predictions  were  predominently  within  3 percent  of  measured  steady  state  performance. 

Engine  simulation  frequency  response  requirements  depend  upon  the  frequency  response  of 
the  control  parameters.  Most  of  the  conventional  control  parameters  such  as  fuel  flow, 
rotor  speeds,  and  burner  pressure  are  influenced  primarily  by  rotor  inertia  effects, 
and  a frequency  response  of  10-20  Hz  is  adequate.  Other  control  parameters  intended 
to  detect  and  control  higher  response  phenomena  such  as  incipient  compressor  stall  or 
afterburner  rumble  require  a much  higher  (50-100  Hz)  simulation  frequency  response. 

For  a development  program  in  which  a hybrid  simulation  is  available  (Section  4.3),  these 
high  frequency  phenomena  may  possibly  be  implemented  in  the  hybrid  simulation  if 
required.  Controller  response  to  the  signal  in  question  can  be  verified  on  the  hybrid 
without  a significant  increase  in  simulation  complexity  by  use  of  a relatively  simple 
simulation  intended  only  to  duplicate  the  input-output  characteristics  of  the 
phenomena  and  not  its  physical  processes. 

If  a requirement  exists  to  study  in  detail  the  particular  phenomena  in  question  a 
separate  specialized  simulation  may  be  required. 

4. 2. 1.2  Inlet  Simulation 

Computer  technology  has  progressed  to  the  point  where  fairly  detailed  and  accurate 
simulations  of  inlet  flowfields  are  possible.  These  simulations  are,  however,  expensive 
in  computer  time  and  core  space  so  that  the  question  of  the  level  of  detail  and  fidelity 
required  for  propulsion  control  development  must  be  addressed  here.  In  general,  the 
inlet  simulation  must  be  able  to  predict  flow  conditions  (pressure,  temperature, 
distortion)  at  the  compressor  face  to  support  the  engine  simulation  and  it  must  predict 
control  signals  well  enough  to  support  inlet  controls  development.  (It  may  also  be 
necessary  in  some  future  program  to  predict  the  external  flowfield  to  support  the 
development  of  flight  controls,  but  since  that  problem  was  not  addressed  in  the  IPCS 
program,  there  is  no  basis  for  a discussion  here). 

It  appears  at  this  time  that  a one-dimensional  compressible  flow  model  supported  by 
empirical  (i.e.,  test)  data  is  adequate  for  controls  development.  A simple  two-lump 
compressible  flow  model  was  used  on  the  IPCS  program.  (A  block  diagram  is  shown  by 
Figure  2.2-1,  volume  II.)  The  empirical  pressure  recovery  data  were  biased  by  a 
throat  Mach  number  parameter.  Simple  first  order  lags  applied  to  the  inlet  control 
signals  and  the  two-lump  duct  volume  provided  the  only  simulation  of  duct  dynamics. 

It  should  be  noted,  however,  that  the  inlet  control  loops  were  not  closed  on  inlet 
aerodynamics. 

It  is  possible  to  make  major  simplifications  in  the  inlet  simulation  equations  by 
working  with  the  critical  flow  area.  A*,  rather  than  Mach  number.  A simple  constant 
relates  A*  to  corrected  weight  flow,  i.e..  A*  = .02022  WAR2  where  A*  is  given  in 
square  feet  and  WAR2  is  given  in  pounds  per  second.  The  ratio  A*/A  (or  reciprocal)  is 
a unique  continuous  function  of  Mach  number,  with  continuous  derivatives  in  a flow 
field  that  is  either  uniformly  subsonic  or  uniformly  supersonic.  Thus  any  function 
of  Mach  number  may  readily  be  mapped  into  a function  of  A*/A.  It  is  possible  to 
integrate  the  flow  into  and  out  of  a control  volume  but  it  may  be  preferable  to  apply 
compensation  to  the  model  predictions  using  e.g.,  the  method  of  Willoh,  reference  3 
to  generate  transfer  functions. 
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The  simulation  of  large  amplitude  disturbances  such  as  inlet  start,  unstart,  or  buzz 
represent  a difficulty  for  a low  frequency  digital  simulation,  as  do  related  phenomena 
(stall,  etc.)  for  the  engine.  When  these  phenomena  require  study  in  their  own  right  a 
separate  simulation  should  be  provided.  For  IPCS  with  a familiar  airframe  and  external 
compression  inlet  this  was  not  necessary.  Under  other  circumstances  it  may  be.  In  any 
case  a crude  model  of  such  phenomena  should  be  provided  in  the  hybrid  simulation  to 
verify  controller  logic.  The  IPCS  inlet  model  could  be  made  to  oscillate  by  programming 
an  artificial  recovery  curve  for  airflows  below  the  buzz  threshold,  so  that  recovery 
decreased  as  airflow  decreased.  It  cannot  be  claimed,  however,  that  this  oscillation 
represented  buzz,  or  that  it  approximated  buzz  better  than  a sinusoidal  or  saw-tooth  wave 
form  or  a duct  empty-fill  cycle.  Nevertheless  the  closed  loop  buzz  control  system 
response  produced  by  this  model  was  an  adequate  representation  of  installed  performance, 
indicating  the  utility  of  such  crude  models  in  controller  design. 

4. 2. 1.3  Digital  Simulation  Configuration 

It  is  very  difficult  to  define  precisely  the  fidelity  and  details  that  must  be  provided 
by  the  digital  simulation.  Some  aspects  of  this  were  discussed  in  earlier  paragraphs. 

The  organization  of  the  program,  on  the  other  hand,  has  a strong  bearing  on  its  usefullness 
and  the  ease  and  economy  with  which  it  can  be  applied.  IPCS  experience  and  recommendations 
in  this  area  are  discussed  below. 

Most  modern  large  scale  engine  simulations,  including  SOAPP,  use  a predictor-corrector 
technique  that  permits  the  simulation  to  advance  through  time  in  relatively  large  steps, 
say  0.1  second.  This  has  two  import  ramifications.  First,  there  is  the  obvious  limit  on 
the  frequency  response  of  the  simulation.  That  has  not  been  a significant  limitation  to 
date  although  it  may  be  a problem  with  some  future  engines.  The  second,  and  more 
important  consequence  follows  from  the  fact  that  the  digital  controller  uses,  typically, 
a sampling  interval  shorter  than  0.1  second.  There  is  a fundamental  incompatibility 
when  a digital  subsystem,  operating  on  a short  time  step,  is  programmed  into  a simulation 
that  runs  at  a longer  time  step.  The  most  obvious  result  of  this  is  that  the  iteration 
technique  will  frequently  fail  to  converge  when  minor  changes  are  made  to  the  control 
algorithm  during  the  development  phase.  Furthermore,  the  control  mode,  as  programmed 
on  the  digital  simulation,  is  one  step  further  removed  from  the  flight  software.  Some 
of  the  IPCS  contractor  personnel  feel  that  there  is  very  strong  incentive  to  run  the 
digital  simulation  at  time  steps  corresponding  to  the  controller  sampling  interval. 

The  cost  impact  associated  with  running  the  simulation  at  the  controller  sampling  interval 
cannot  be  assessed  at  this  .time.  First  of  all,  simulation  computer  time  is  not 
necessarily  directly  proportional  to  the  inverse  of  the  simulation  interval,  halving  the 
simulation  interval  will  'not  double  the  computer  time.  Secondly,  most  computer  accounting 
methods  are  set  up  so  that  computer  time  is  only  a portion  of  the  total  charge.  Finally, 
it  is  not  possible  to  price  the  impact  of  running  the  simulation  at  time  steps  other  than 
the  sampling  interval.  The  problem  was  not  clearly  identified  on  the  IPCS  program  in 
time  to  estimate  the  cost  increment.  Thus  we  can  only  call  attention  to  the  situation  at  this 
time  and  urge  that  it  be  addressed  from  the  very  start  of  any  future  program. 

Figure  4.2-3  is  a propulsion  system  digital  simulation  program  configuration  that  would 
isolate  the  various  parts  of  the  propulsion  system  control.  This  configuration  would 
allow  the  control  algorithm  to  be  contained  in  one  routine  and  will  simplify  the  mode 
software  definition  as  discussed  below.  Separate  modules  for  sensors  and  actuators  will 
permit  ease  of  handling  measurement  noise  and  errors  and  interface  hardware  dynamics  and 
simplify  maintenance  of  the  simulation. 

The  control  algorithm  should  resemble  the  desired  flight  software  configuration  as 
closely  as  possible.  It  should  use  the  same  equations,  in  the  same  order,  since  the 
order  in  which  calculations  are  performed  affects  the  result.  Units,  sign  conventions, 
and  coordinate  systems  should  reflect  actual  hardware.  If,  as  was  the  case  in  IPCS, 
sign  changes  and  offsets  in  various  servo  loops  were  distributed  amongst  sensors, 
actuators,  electronics,  and  software,  each  element  should  be  represented  algebraically 
even  if  its  dynamics  are  not  significant. 
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Figure  4.2-3  Digital  Propulsion  Simulation  Configuration 
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Logic  networks  should  be  identical.  Techniques  used  for  digital  filtering  should  be 
identical;  if,  for  example,  Tustin's  method  is  used  in  the  flight  software,  then  Tustin's 
method  should  be  used  in  the  simulation.  It  should  in  fact  be  possible  essentially  to 
reproduce  the  FORTRAN  listing  of  the  control  module  in  the  document  that  is  used  to 
specify  the  flight  software  requirements.  This  will  save  a significant  amount  of  labor 
and  will  eliminate  an  important  error  source.  Extensive  use  of  comments  in  the  FORTRAN  will 
further  assist  in  formal  documentation. 

4. 2. 1.4  Field  Deck  Procedure  and  Alternatives 

The  design  procedure  agreed  upon  at  the  early  IPCS  joint  design  sessions  with  all 
contractors  was  to  provide  a field  deck  for  each  contractor  to  use.  (The  term  "field 
deck"  refers  to  a digital  program  prepared  by  one  contractor  and  released  for  out-plant 
use  by  other  contractors  or  governmental  agencies.)  This  not  only  permitted  each 
contractor  to  evaluate  the  mode  concepts,  but  also  to  use  the  deck  for  establishing 
their  contribution  to  the  mode  design.  The  decks  were  issued  in  source  format  to  permit 
ease  of  deck  operations  to  change  the  mode. 

Field  decks  were  issued  at  various  times  in  the  design  process  as  determined  by  the 
extent  of  program  changes  in  effect  at  P&WA.  The  BOMDIG  mode  deck  was  issued  twice, 
once  for  definition  of  the  mode  for  baseline  comparisons,  and  the  final  version  was 
issued  to  provide  an  update  of  the  inlet/engine  model  based  upon  test  results.  The 
IPCS  deck  was  issued  five  times  at  various  levels  of  mode  refinement,  in  an  attempt 
to  maintain  a level  of  consistency  with  the  models  used  for  mode  design  by  each 
contractor. 

Issuance  of  a field  deck  is  an  expensive  operation  requiring  large  amounts  of  engineer 
and  programmer  manpower  and  computer  time.  Expenditure  of  these  resources  for  field 
deck  operations  detracts  from  those  normally  available  in  the  design  phase.  Careful 
consideration  should  therefore  be  given  to  the  approach  used  in  future  programs  in  order 
to  satisfy  both  budgetary  and  schedule  constraints.  Some  of  the  alternatives  are 
presented  below.  In  considering  these  alternatives  it  is  necessary  to  bear  in  mind 
that  both  the  engine  and  the  airframe  manufacturer  may  need  to  perform  extensive 
simulation  studies  for  purposes  other  than  propulsion  control  development.  Furthermore, 
the  customer  may  require  access  to  a simulation  on  a regular  basis  in  the  interest  of 
maintaining  visibility  and  program  control. 

The  following  alternatives  were  identified  during  discussions  among  IPCS  contractor 
personnel : 

1.  Issue  field  decks  in  modular  form  as  diagrammed  in  Figure  4.2-3. 

Minimize  the  number  of  updates  and  update  only  those  modules  that 
have  changed  significantly. 

2.  Co-locate  all  control  designers  (i.e.,  from  the  engine,  airframe, 
and  control  manufacturers)  at  one  facility  during  the  development 
program. 

3.  Communicate  all  simulation  requirements  to  a single  site  (by  mail, 
telecon,  telefax,  etc.)  where  the  runs  are  made  and  the  results 
transmitted  back  to  the  sender. 

4.  Run  all  simulations  on  a common  computer.  Users  communicate  with 
this  computer  via  telephone  links  and  remote  terminals. 

The  major  advantages  and  disadvantages  of  each  of  these  alternatives  are  listed  in 
Table  4.2-1. 
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Table  4.2-1  TRADES  IN  LOGISTICS  OF  DIGITAL  SIMULATION 


METHOD 

1.  Issue  field  decks 


2.  Colocate  designers 


3.  Communicate 
requirements  to 
single  site 

4.  Remote  terminal 

to  single  computer 

4.2.2  Hybrid  Simulation 


ADVANTAGES 

All  users  have  ready 
access  to  simulation 
on  their  own  computers. 
Minimum  intercompany 
accounting  problems. 

Decks  available  for 
studies  other  than 
propulsion  control 
development. 

Minimum  computer  expense 
Close  communication 
between  engine/airframe/ 
control  manufacturers  and 
control  designers. 


Minimum  computer  usage 


Ready  access  as  in  1 . 


DISADVANTAGES 

Expense  and  inconvenience 
of  preparing  field  decks 
and  educating  users. 


"Outplant"  personnel 
lose  contact  with 
their  home  organizations. 
Difficult  to  maintain 
continuity  of  personnel. 
Possible  personnel 
problems.  Travel  and 
maintenance  expense. 
Simulation  not  generally 
available  for  other  uses. 

Serious  communication 
problems.  Long  turn- 
around times.  Tendency 
to  skimp  on  simulation 
studies 

Expense  of  terminal 
and  phone  link. 


4.2.2. 1 Use  of  Hybrid  Simulations  for  Propulsion  Control  Development 

The  main  tool  for  control  studies  at  Honeywell  was  the  non-linear  engine  simulation  using 
the  hybrid  computer.  This  simulation  was  driven  in  two  modes.  10-to-l  slow  time  with  the 
control  algorithms  programmed  in  FORTRAN  on  a SIGMA  V computer  and  a real-time  mode  with 
the  assembly  language  control  algorithms  programmed  on  the  actual  digital  computer  to  be 
used  in  flight.  There  was  a very  large  step  involved  in  going  from  the  FORTRAN  to  the 
DAP-16  assembly  language  used  in  the  real-time  program.  For  example,  the  FORTRAN  program 
did  not  address  the  I/O  problems  associated  with  actual  sensors  and  actuators.  An 
evaluation  of  memory  and  computing  speed  requirements  based  on  the  FORTRAN  listing  would 
have  given  erroneous  answers.  Individual  compensation  and  functions  used  to  obtain 
better  accuracy  and  scaling  of  both  sensors  and  output  commands  used  up  more  resources 
than  generally  expected. 


The  slow-time  FORTRAN  simulation  was  used  at  Honeywell  to  study  sample  time  effects.  The 
results  of  one  of  these  studies  are  shown  In  Figure  4.2-4.  One  of  the  interesting 
conclusions  was  that  care  should  be  used  in  implementing  block  diagrams  drawn  by  persons 
unfamiliar  with  digital  control  requirements.  Difficulty  in  the  BOMDIG  development  was 
encountered  when  block  diagrams  describing  logical  operations  were  drawn  in  arithmetic 
form  and  combinations  of  logical  and  arithmetical  statements  were  used  in  the  generated 
program. 

The  sample  times  --  both  for  the  major  sample  and  the  minor  sample  times  (a  multiple  of 
five  milliseconds)  --  shown  to  be  adequate  for  BOMDIG  and  IPCS  were  then  used  when 
programming  and  studying  control  behavior  in  real-time. 


The  hybrid  facility  was  used  jointly  by  two  programs  on  a day-to-day  basis,  the  IPCS 
program  and  the  Space  Shuttle  Main  Engine  Control  program.  About  one-half  hour  was 
required  to  change  over  from  one  simulation  to  the  other.  Once  set  up,  a flight 
condition  could  be  changed  in  about  10  minutes  by  simply  loading  in  a deck  of  cards 
which  defined  the  new  pressure  and  temperature  conditions  and  Initialized  the  engine 
at  the  new  conditions.  Real  to  slow-time  transition  was  obtained  by  simply  throwing 
one  switch  which  simultaneously  changed  all  the  capacitor  values  on  the  integrators. 


SAMPLE  RATE  - 20  MS 


IPCS  CONTROL  (N2) 
WFp- 6,300  LB/HR 
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The  non-linear  hybrid  engine  simulation  was  set  up  in  terms  of  "corrected"  or  generalized 
parameters.  This  was  required  for  the  compressor  because  a supersonic  inlet  delivered  a 
variable  compressor  face  total  pressure  but  in  addition,  the  flexibility  provided  by  the 
generalized  maps  used  allowed  flight  conditions  to  be  changed  quickly. 

All  of  the  integrators  were  in  the  analog  portion  of  the  hybrid  and  so  were  not  affected 
significantly  by  the  computing  speed  of  the  digital  part  of  the  hybrid.  This  digital  part  of 
the  simulation  was  used  for  compressor  map  functional  generation  as  well  as  for  those  other 
non-linear  engine  relationships  requiring  complex  functional  descriptions.  Computing  time  was 
on  the  order  of  five  milliseconds  to  complete  all  required  calculations.  A rough  rule  of  thumb 
is  that  six  to  eight  "points"  are  required  to  define  a sine  wave.  At  a five  millisecond  sample 
time  this  indicates  that  the  Honeywell  hybrid  simulation  may  be  used  for  control  studies  in  the 
frequency  range  to  25  Hz.  Good  frequency  response  is  particularly  required  in  the  study  and 
evaluation  of  engine  control  loops  such  as  turbine  inlet  temperature,  compressor  discharge 
pressure  and  Mach  number  and  A/B  phenomena  affecting  engine  back  pressure.  Also,  the  switching 
characteristics  when  going  from  one  control  mode  to  another  may  be  regarded  as  a high  frequency 
problem  in  that  precise  definition  of  the  time  when  switching  should  occur  requires  a good  high 
frequency  engine  definition.  This  was  particularly  noticeable  in  the  IPCS  program  where  a 
complete  low  frequency  digital  simulation  of  a suggested  control  change  indicated  behavior  that 
was  not  attainable  when  the  change  was  actually  implemented  on  the  aircraft. 

The  hybrid  simulation  proved  invaluable  in  two  major  areas  --  it  allowed  many  hours  of  software 
"debug"  time  in  an  actual  real  time  environment  and  it  provided  the  only  tool  to  study  some 
destabilizing  control  aspects  not  evaluated  anywhere  else.  The  all-digital  simulation  did  not, 
for  instance,  simulate  the  stepper  motor  used  in  the  exhaust  nozzle  controller.  This  motor 
could  drive  at  the  rate  of  15  steps/30  milliseconds  and  so,  therefore,  could  drive  for  half  a 
sample  period  and  stop  part  way  through  the  period.  The  proper  control  configuration  for  this 
loop  was  evaluated  on  the  hybrid.  It  could  have  been  also  on  a complete  digital  simulation  by 
using  much  finer  time  increments.  The  cost  of  the  digital  simulations  would  have  increased 
very  significantly. 

The  many  hours  of  software  debug  time  provided  by  the  hybrid  allowed  many  of  the  coding  problems 
such  as  overflow,  scaling  errors,  plain  coding  errors  and  dynamic  compensation  problems  to  be 
corrected  before  they  became  expensive.  This  was  a significant  contribution  in  saving  of  time 
and  expense  during  the  bench,  wind  tunnel  and  flight  phases  of  the  program. 

In  any  future  programs,  many  hours  of  software  "debug"  time  against  a real  time  engine  simulation 
will  prove  invaluable  in  both  cost  and  time  when  considered  against  the  alternatives  of  later 
schedule  impact  due  to  ill-defined  software  configurations.  Such  studies  will  be  particularly 
important  in  production  programs  where  large  margins  in  memory  and  computing  speed  may  not  be 
availaDle  and  I/O  skew  problems  may  be  much  more  significant. 

The  actual  real  time  computer  program  was  evaluated  on  the  hybrid  computer  at  four  flight 
conditions.  These  were  sea  level  static;  0.9  Mach,  45,000  feet  altitude;  1.6  Mach,  45,000  feet 
altitude;  and  2.1  Mach,  45,000  feet  altitude.  The  rationale  for  this  choice  of  conditions  is 
as  follows:  Conditions  of  constant  total  pressure  at  the  compressor  face  may  be  imposed  at 

given  points  in  an  aircraft  flight  envelope  if  the  supersonic  inlet  is  assumed  operating  at  its 
design  condition.  This  pressure  is  the  primary  forcing  function  in  determining  the  pole-zero 
location  of  the  engine  characteristics.  The  pole-zero  locations  are  affected  only  in  a relatively 
minor  way  by  compressor  face  total  temperature.  Hence  checking  the  engine  at  the  above  four 
flight  conditions  can  be  interpreted  as  a check  of  many  other  flight  conditions  also,  i.e., 
those  with  the  same  compressor  face  total  pressure.  Sea  level  static  is  used  because  most  of 
the  initial  engine  running  is  done  at  that  condition,  0.9  Mach  because  this  is  perhaps  the 
minimum  total  pressure  to  be  encountered,  2.1  because  this  is  both  a supersonic  inlet  operating 
condition  as  well  as  a maximum  or  large  total  pressure  condition  and  1.6  Mach  as  a median  case 
for  which  the  inlet  surfaces  were  also  modulated  in  flight. 
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As  stated  in  Volume  II  the  IPCS  program  was  designed  to  be  a conservative,  success 
oriented  program.  Therefore,  control  development  paths  were  followed  which  were  known 
to  be  successful  and  would,  therefore,  contribute  to  a minimum  of  program  extensions 
during  the  expensive  phases  of  the  bench  and  engine  test  program.  As  a matter  of  fact, 
the  test  programs  in  these  phases  were  shortened  from  those  originally  planned.  This 
reduction  was  possible  only  because  of  the  thorough  software  verification  process 
conducted  in  the  non-expensive  areas  of  the  program  --  when  bench,  engine,  wind  tunnel, 
and  flight  test  facilities  were  not  impacting  the  costs. 

4. 2. 2. 2 Real  Time  Plant  Simulation  (RTPS)  Recommendations 

As  discussed  above,  some  form  of  real  time  plant  simulation  is  essential  for  in-house 
checkout  and  development  of  controller  hardware  and  software.  The  same  simulation 
capability  is  necessary  for  closed  loop  bench  testing.  Finally  the  RTPS  is  required  at 
each  engine  test  site  to  verify  software  and  troubleshoot  controller  problems  with  a 
minimum  of  engine  run  time.  This  leads  to  the  conclusion  that  the  RTPS,  in  addition 
to  being  a detailed  real  time  simulation,  should  be  portable  and  configured  to  permit 
rapid  substitution  of  it  for  the  engine  or  elements  thereof.  The  following  paragraphs 
define  the  RTPS  requirements  based  on  IPCS  experience,  and  present  a basic  simulation 
configuration. 

The  RTPS  performs  three  functions: 

1)  Provides  closure  of  all  control  loops  associated  with  the  controller, 

2)  Facilitates  study  of  conditions  and  phenomena  not  feasible  with  other 
simulations  - start,  buzz,  rumble,  failure  modes,  finite  word  length 
and  interface  effects 

3)  Provides  test  crew  training  in  troubleshooting  and  hands-on  experience 
with  real  time  operation  of  the  control  system  hardware  and  software. 

During  the  early  part  of  a development  program  these  functions  permit  development  of 
controller  hardware  design  in  a relatively  efficient  manner  and  independent  verification 
of  controller  design  and  digital  simulation  performance  early  in  the  design  process. 

Later  the  RTPS,  its  configuration  stabilized,  provides  an  indispensable  tool  for  software 
checkout  and  troubleshooting. 

In  order  to  perform  the  above  functions,  the  RTPS  must  meet  various  requirements. 

In  those  areas  where  comparison  is  possible  the  RTPS  must  accurately  replicate  the 
large  scale  digital  engine  simulation.  The  degree  of  accuracy  required  is  best  expressed 
qualitatively  - if  the  controller  must  be  changed  to  accommodate  the  RTPS  or  if  the 
RTPS  tends  to  become  a scape-goat  for  system  problems  it  is  inadequate.  Techniques  for 
conversion  of  large  scale  digital  simulations  to  equations  suitable  for  RTPS  use  are 
currently  being  developed  at  P&WA.  Since  these  techniques  are  automated  they  promise 
to  be  superior  to  developing  a separate  RTPS  math  model  from  first  principles.  Caution 
should  be  exercised  in  their  use,  however,  since  they  will  tend  to  eliminate  the 
inherent  double  check  provided  by  an  independent  simulation. 

The  RTPS  should  represent  all  phenomena  that  the  controller  is  designed  to  sense  or 
control.  Problems  were  found  in  the  field  in  most  control  functions  not  thoroughly 
checked  by  simulated  closed  loop  operation  - buzz  and  stall  are  examples.  These 
representations  need  not  be  terribly  precise  - cases  must  be  considered  on  their  own 
merits.  As  a rule  of  thumb,  one  should  remember  that  any  reasonable  controller  should 
tolerate  at  least  2:1  gain  variation  in  the  forward  loop;  hence  the  plant  simulation, 
if  only  critical  for  functional  checkout,  need  only  be  this  good. 

The  RTPS  must  be  portable  and  adaptable  to  use  in  various  test  facilities.  This 
implies  use  of  current  technology  in  implementing  it.  Current  technology  will  also 
provide  more  repeatable,  reliable  operation  and  simpler  interfaces.  Portability  and 
adaptability  are  essential  to  permit  use  of  one  simulation  for  all  field  support 
activities,  reducing  development  costs  and  repeatability  problems. 
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Those  sections  of  the  simulation  representing  engine  performance  and  fixed  system 
elements  should  be  subject  to  good  configuration  control  in  the  field  This  is  essential 
to  provide  repeatable  simulation  results.  However,  plentiful  accessible  spare  capacity 
should  be  provided  in  the  RTPS  to  meet  unanticipated  simulation  requirements. 

Finally,  one  person,  preferrably  one  of  the  developers  of  the  RTPS  should  be  assigned  to 
provide  field  support  of  the  RTPS  throughout  the  test  program.  Th,is  is  essential  if  the 
RTPS  is  to  provide  the  continuous  reliable  support  required  of  it. 

The  simulation  should  have  the  configuration  shown  in  Figure  4.2-5.  The  Actuator 
Simulation  Section  provides  detailed  simulation  of  controller  loads,  actuator  dynamics, 
and  actuator  servo  loop  closure  feedback  signals.  Where  cost  effective,  actual  hardware 
may  be  incorporated  in  this  section.  The  output  of  the  Actuator  Simulation  Section  is 
a set  of  scaled  plant  input  variables  - fuel  flows,  bleed  states,  etc.  The  engine  and 
inlet  simulation  are  implemented  electronically  in  a manner  permitting  simulation  of 
phenomena  over  the  entire  range  of  frequencies  expected  in  and  of  interest  in  the  plant. 
Noise  generators  may  be  incorporated  where  appropriate. 

The  Sensor  Simulation  Section  converts  scaled  variables  output  by  the  Engine/Inlet 
simulation  to  simulated  transducer  outputs. 

The  RTPS  is  constructed  to  permit  interfacing  with  flow  bench  hardware  by  breaking 
connectors  at  the  interface  between  the  Engine/Inlet  Simulation  and  the  I/O  sections. 

By  making  this  simulation  an  integral  part  of  the  Propulsion  System  Test  Equipment  program 
costs  and  schedules  will  be  reduced  since  the  simulation  will  be  available  for  use  at  all 
times.  Thus  software  field  changes  may  be  checked  out  quickly  on-site  without  incurring 
engine  or  bench  user  time  penalities  and  the  risk  of  damage  to  engine  hardware  through 
software  errors. 

Spare  capacity  is  provided  in  each  section  of  the  simulation  to  permit  adding  details  or 
new  elements  to  the  simulation.  Depending  on  the  scope  of  the  controller,  the  RTPS  may 
incorporate  additional  features  - aircraft  rigid  body  dynamics  for  example.  The 
dedicated  parts  of  the  RTPS  should  be  fully  defined  and  checked  out  prior  to  Bench  Test. 
Thus  the  entire  unit  can  come  under  rigid  configuration  control  when  it  leaves  the 
vendors  plant.  This  will  assure  a consistent  documented  simulation  throughout  the 
remainder  of  the  development  program. 

4.2.3  Stability  Models 

Gas  turbine  engines  are  notoriously  non-linear.  Most  of  the  discontinuities,  however, 
occur  at  operating  boundaries,  so  that  the  engine  may  be  considered  piecewise  linear 
vver  much  of  its  operating  envelope.  The  designer  has  several  options.  He  may  elect 
o represent  the  controller  as  a set  of  single-inout , single-output  loops  and  apply 
root-locus  or  other  standard  linear  methods.  Alternatively,  it  may  be  possible  to 
estimate  values  of  gain  and  the  form  of  compensation  that  will  give  satisfactory 
performance.  A simplified  simulation  may  be  set  up  to  evaluate  these  by  stepping 
through  a range  of  gains,  time  constants,  etc.,  comparing  the  system  response  to 
standard  disturbances.  Combinations  of  these  techniques  have  been  used  successfully 
in  many  situations. 

The  rapidly  developing  science  of  optimal  control  theory  offers  a third  alternative  that 
may  eventually  be  far  superior  to  the  others.  This  technique  optimizes  multiple  input, 
multiple  output  systems  to  predetermined  criteria  that  are  programmed  on  the  computer. 

The  constraints  of  single-input,  single-output  loops  are  eliminated,  the  process  is 
highly  automated,  and  the  computer  applies  the  optimization  criteria  consistently. 

4. 2. 3.1  Extraction  of  Linear  State  Models 

Linear  state  models  are  extracted  from  the  SOAPP  simulation  via  perturbation  techniques. 
(See  Appendix  to  Vol  II.)  These  procedures  have  progressed,  reducing  time  and  manpower 
required  for  model  extraction,  such  that  special  subroutines  for  the  purpose  are 
compiled  with  the  non-linear  digital  model  of  the  propulsion  system  and  automatically 
provide  linearized  models  at  the  operating  point  of  interest  upon  request. 


4.2. 3.2  Transfer  Function  Generation  Techniques 

Having  found  the  system  matrices  by  perturbation  techniques  transfer  functions  are 
obtained  using  State  Variable  Techniques.  The  state  variable  representation  of  a linear 
system  consists  of  the  following  two  Matrix  equations: 

X = A X + BU 
Y = C X + DU 

where  X is  the  vector  of  state  variables  such  as  pressures  and  rotor  speeds,  U is  the 
vector  of  control  inputs  such  as  fuel  flow,  and  Y is  the  vector  of  observed  parameters 
such  as  airflow  and  Mach  numbers.  The  plant  matrix.  A,  and  its  elements  are  the 
partials  from  each  state  variable  to  each  state  variable  time  derivative.  The  control 
matrix,  B,  defines  the  effect  of  each  control  input  on  each  state  variable  time 
derivative.  The  output  matrix,  C,  defines  the  relationship  between  the  observed 
parameters  and  the  state  variables,  and  the  output  matrix,  D,  defines  the  relationship 
between  the  observed  parameters  and  the  control  input,  U. 

The  above  equations  are  manipulated  using  Matrix  operations,  and  substituting  the 
Laplace  operator  "S"  for  time  derivatives  results  in  the  following  equation  for  transfer 
functions : 

G(S)=  -J-  - C(SI-A)"1  B+D;  j * (SI-A)"1  B 
where  I is  the  Identity  Matrix. 

The  state  variable  technique  for  extracting  transfer  functions  from  the  non-linear  model 
has  been  found  to  be  the  most  cost  effective  and  accurate  procedure  to  date. 

The  chief  computational  problem  is  in  the  calculation  of  (SI-A)  1 for  high  order  systems. 
The  form  of  (SI-A)'1  is  that  of  a rational  function  consisting  of  a matrix  polynominal 
numerator  defining  all  possible  transfer  function  numerators  and  a scalar  polynominal 
denominator  which  is  the  characteristic  polynominal  of  the  A matrix.  Clearly  the  roots 
of  this  characteristic  polynominal  are  the  eigenvalues  of  the  A-  matrix  and  also  are 
the  poles  of  the  system  transfer  functions. 

Methods  such  as  Leveriers  Algorithm  (4)  attempt  to  compute  (SI-A)1  in  its  entirety  by 
the  use  of  high  powers  on  the  A-matrix  which  is  not  numerically  sound.  In  addition  the 
characteristic  polynominal  is  formed  and  rooted  for  the  poles  - again  a numerically 
unsound  procedure  for  high  order  systems. 

The  best  technique  is  to  obtain  the  eigenvalues  of  A by  the  QR  transformation  (5), 
multiply  the  eigenvalues  together  to  form  the  characteristic  polynominal  and  then  use  a 
more  modern  method  for  the  numerators  (6),  (7)  which  only  attempt  to  produce  a single 
transfer  function  numerator  at  a time. 

The  method  of  Patel  (6)  is  easily  coded  and  requires  the  determination  of  two  matrix 
characteristic  polynominals,  the  desired  transfer  function  numerator  polynominal  then 
being  found  as  the  difference  between  the  two  characteristic  polynominals.  Provided 
sufficient  precision  is  retained  in  the  polynominal  coefficients  by  working  via 
eigenvalues,  the  method  is  numerically  sound. 

The  method  due  to  Davison  (7)  appears  to  be  numerically  sound  but  somewhat  more  difficult 
to  use  since  it  determines  transfer  function  zeros  as  the  eigenvalues  of  a specially 
constructed  matrix,  which  do  not  tend  to  infinity  as  certain  constants  within  the  matrix 
change  value. 

Thus  the  program  is  required  to  partition  the  matrix  eigenvalues  into  two  groups,  one 
lending  to  infinity,  the  other  remaining  substantially  constant.  The  constant  group 
are  the  desired  zeros. 

Both  methods  are  practical,  the  difference  is  mainly  one  of  convenience. 
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4.2. 3. 3 Selecting  the  State  Variables 


The  correct  selection  of  the  state  variables  is  necessary  to  result  in  transfer  functions 
that  contain  meaningful  frequency  content.  Minimizing  the  number  of  states  will  also 
serve  to  simplify  the  data  and  minimize  processing  cost. 

For  linear  model  generation,  the  following  factors  should  be  considered  to  arrive  at  the 
minimum  order  model  possible: 

States  with  dynamics  more  than  one  decade  higher  in  frequency  than 
the  frequency  range  of  interest  are  usually  ignored. 

Frequency  range  of  interest  should  be  determined  from  sensor  and 
actuator  response  characteristics.  In  other  words  if  it  is  desired 
to  control  some  high  response  state  but  available  sensor  and 
actuator  responses  are  not  fast  enough  to  "sense  and  control"  these 
states,  there  Is  little  incentive  to  include  these  states  in  the 
1 inear  model . 

Other  states  with  slower  response  can  also  be  eliminated,  but  the 
validity  of  doing  this  must  be  evaluated  on  the  nonlinear  model  - 
i.e.,  evaluate  impact  on  resultant  closed  loop  performance  - and 
also  eliminate  states  associated  with  low  frequency  poles  which 
are  nearly  cancelled  by  zeros  (such  as  heat  storage  states)  since 
these  will  have  little  impact  on  closed  loop  response. 

The  number  of  states  in  the  simplified  linear  model  must  be  no  less 
than  the  number  of  desired  isochronous  control  loops;  i.e.,  the 
model  must  have  as  many  degrees  of  freedom  as  there  are  independent 
integral  control  loops.  This  may  require  including  some  states 
associated  with  higher  frequency  dynamics. 

The  most  general  way  to  generate  a linear  model  is  to  generate  the  full  state  model  and 
then  use  a modal  analysis  procedure  in  which  system  eigenvalues  are  calculated,  and  a 
set  of  eigenvalues  are  selected  for  elimination  from  which  the  appropriate  states  to 
be  eliminated  can  be  back  calculated. 

The  number  of  states  should  be  agreed  upon  by  the  design  team  before  the  design  process 
gets  to  the  gain  and  compensation  design  phase.  Models  with  a minimum  number  of  states 
consistent  with  the  above  criteria  should  be  selected.  This  will  avoid  the  time 
consuming  process  of  inverting  higher  order  state  matrices  (SI-A),  saving  manpower  and 
computer  time  required  to  process  the  data. 

It  is  recommended  that  the  extraction  of  linear  models  be  performed  in  a continuous 
operation  at  one  contractor  location.  The  preferred  location  would  be  the  one  with 
the  greatest  expertise  in  operating  the  non-linear  propulsion  system  model  and  the 
associated  model  extraction  subroutines.  This  will  avoid  the  unnecessary  transmittal 
of  perturbation  data  and  lost  time  associated  with  dividing  the  process  among 
contractors. 

4. 2. 3. 4 Classical  Operations  on  Linear  Models 

Classical  methods  of  control  analysis  were  applied  successfully  during  the  IPCS 
program.  The  procedure  used  is  as  follows: 

Generate  linear  state  models  at  a series  of  operating  conditions. 

Compute  transfer  functions  from  the  linear  state  models. 

Construct  a series  of  point  designs,  using  root-locus,  Bode  or 
other  recognized  methods. 

Program  schedules  of  gains  and  time  constants  as  functions  of 

characteristic,  unifying  operating  variables.  (PS3  was  used) 
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The  following  criteria  were  adopted  as  goals  to  be  used  in  controller  compensation  design: 

The  gain  margin  of  all  loops  shall  be  at  least  6 dB. 

Loops  designated  as  limiting  (maximum  or  minimum)  shall  have  no 
overshoot  when  subjected  to  a step  input. 

Overshoot,  where  permitted,  shall  not  exceed  the  value  attained 
under  BOM  control  as  predicted  by  the  SOAPP  simulation. 

Rise  time  of  each  loop  shall  be  as  fast  as  the  value  attained 
under  BOM  control . 

Settling  time  of  variables  shall  not  exceed  that  of  the  BOM 
control  as  predicted  by  the  SOAPP  simulation. 

Candidate  designs  were  tested  over  the  operating  envelope  using  the  SOAPP  simulation  and 
adjusted  as  necessary. 

The  resulting  controller  was  used  with  few  modifications  through  the  entire  test  program  and 
provided  acceptable  results.  However,  more  specific  design  criteria  and  closer  review  of  early 
test  data  would  have  benefitted  the  I PCS  program. 

Based  on  IPCS  experience,  the  anticipated  controller  performance  should  be  formally  documented 
as  a part  of  the  contract  Interface  Control  Document  (ICD)  or  other  specification.  The  anticip- 
ated performance  should  be  defined  in  terms  of  the  parameters  presented  above  -loop  gain, 
margin,  etc.  - and  in  addition  allowable  steady-state  tracking  error  for  each  loop  should  be 
established.  Where  appropriate,  for  example,  gain  margin  and  steady-state  error  budgets 
documenting  tolerance  allowances  should  be  included.  Formal  documentation  of  these  data 
provides  a number  of  benefits: 

1.  Organizes  the  design/analysis  process  around  a focal  point. 

2.  Provides  all  program  management  customer  and  contractor,  with 
visibility  of  system  performance. 

3.  Provides  a reference  to  which  test  data  are  compared  - 
problems  are  more  quickly  identified  and  resolved. 


The  anticipated  controller  performance  is  not  intended  to  be  a contractual  requirement.  Thus  as 
testing  progresses  and  it  is  found  to  be  unnecessarily  tight  in  some  areas  and  too  loose  in 
others  It  should  be  adjusted  based  on  a consensus  of  engineering  judgement  without  contractual 
implications. 

Controller  design  and  modification  using  an  engine  simulation  are  practical  only  if  the  engine 
simulation  adequately  represents  the  engine.  A portion  of  the  antic pated  controller  performance 
documentation  should  define  simulation  requirements  related  to  specific  control  parameters  of 
interest.  As  early  as  possible  in  the  test  program,  compliance  with  hese  requirements  should 
be  documented.  Where  a programmable  digital  controller  is  availab!-,  simulation  fidelity  is 
relatively  easy  to  check  since  the  controller  can  provide  clean  prG  rarmed  fuel  flow  inputs  to 
the  engine;  the  response  is  easily  evaluated  on  the  digital  simulat.on. 


4.2.4  Application  of  Optimal  Control  Theory 

Optimal  Control  Theory  has  been  applied  to  design  of  propulsion  system  controls  to  verify 
suitability  of  the  technique  as  a viable  design  tool.  Confidence  has  been  established  that 
certain  techniques  may  be  used  as  design  tools  for  future  control  mode  study  efforts.  These 
techniques  are: 

1.  Linear  Quadratic  Synthesis  (LQS),  and 

2.  Non-linear  Trajectory  Optimization 


Because  of  the  complexity  of  the  calculations  performed,  these  desi' n tools  are  applied  in  an 
off-line  fashion,  using  computer  simulation  of  the  propulsion  sy.'",  to  determine  the  control 
mode  and  values  of  loop  gains  and  compensation.  Generalized  compute’  programs  now  exist  for 
performing  these  analyses.  LQS  can  be  applied  efficiently  to  the  design  of  small  perturbation 
and  regulator  controls  for  either  single-input,  single-output,  or  multi-input,  multi-output 
systems.  The  nonlinear  trajectory  optimization  technique  can  be  applied  to  optimizing  large 
perturbation  transients  with  the  resulting  transients  on  engine  and  control  variables  used  to 
determine  the  best  way  to  schedule  the  transient  references  for  the  regulator  control. 
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Also,  the  nonlinear  technique  can  be  applied  to  the  optimization  of  gains  of  a preselected 
control  mode  structure  or  to  the  reoptimization  of  LQS  derived  feedback  gains  in  the 
event  that  important  gain  terms  have  to  be  abandoned  due  to  such  problems  as  inability 
to  sense  the  required  engine  variable  for  the  feedback  loop. 

4.2.4. 1 Non-Linear  Trajectory  Optimization 

The  non-linear  optimization  program  requires  a non-linear  simulation  of  the  plant  being 
controlled,  a set  of  nominal  system  input  trajectories,  a set  of  system  constraints, 
and  a performance  index.  The  system  inputs  are  put  into  the  program  by  breaking  down 
their  trajectories  into  a time  series  (optimization  intervals)  and  specifying  the 
value  at  the  end  of  each  interval.  A modified  conjugate  gradient  technqiue  is  then 
used  to  calculate  direction  of  movement  of  each  input  over  each  optimization  interval 
to  improve  the  performance  index.  Supplementary  limiting  calculations  allow  the 
system  to  move  only  along  feasible  directions,  which  result  in  performance  improvement 
without  violating  system  constraints.  The  results  of  this  calculation  are  open-loop 
optimal  trajectories  on  the  system  input  that  provide  optimum  performance. 

The  non-linear  optimization  program  was  not  used  as  a basis  for  control  mode  design 
during  the  IPCS  program,  but  was  applied  to  selected  transient  control  problems  to 
demonstrate  applicability  to  the  mode  design  process.  Optimization  was  demonstrated 
of  the  trajectories  on  main  burner  fuel  flow  (WF)  and  exhaust  nozzle  area  (AO)  to  obtain 
improved  thrust  response  for  a gross  acceleration  at  sea  level  static  conditions. 
Trajectories  were  optimized  on  WF,  AJ,  inlet  spike  position  and  second  cone  angle  to 
obtain  improved  thrust  response  and  distortion  margin  for  an  angle  of  attack  and  engine 
power  transient  at  one  supersonic  flight  condition.  Optimization  of  the  integral  gain 
and  lead  time  constant  for  the  high  compressor  discharge  mach  number  loop  of  the  IPCS 
control  mode  was  also  demonstrated  for  a gross  acceleration  at  sea  level  static 
conditions.  In  all  cases,  the  results  obtained  were  similar  to  those 
obtained  with  the  classical  analysis  procedure.  The  key  benefit  is  that  the  nonlinear 
optimization  technique  accommodates  loop  interaction  effects  and  is  less  dependent  than 
the  classical  approach  on  a trial -and-error  process  and  intuition  of  the  control 
engineer.  This  , in  addition  to  the  application  of  the  technique  to  gross  transient 
optimization  of  other  propulsion  systems  has  established  confidence  in  this  technique 
as  a tool  to  be  used  routinely  in  the  control  mode  design  process. 

4. 2. 4. 2 Linear  Quadratic  Synthesis 

The  linear  quadratic  synthesis  program  is  based  upon  the  piecewise  linear/piecewise 
optimal  design  technique  developed  at  the  United  Technology  Research  Center.  This 
technique  requires  the  1 inearization  of  the  engine  simulation  and  the  solution  of 
the  Matrix  Riccati  equation,  for  a specified  performance  index,  at  selected  operating 
points  to  determine  the  gains  for  a feedback  controller.  Closed  loop  operation 
with  these  gains  is  then  evaluated  on  the  non-linear  engine  simulation  to  determine 
if  the  desired  performance  is  obtained,  and  if  not,  the  gains  are  recalculated  with 
an  appropriately  modified  performance  index. 

The  linear  quadratic  synthesis  technique  (LQS)  design  tool  cannot  be  used  to 
optimize  a gross  transient  response  of  a non-linear  system  directly.  This  may  seem 
like  a very  obvious  statement,  however,  there  has  been  a great  deal  of  misunderstanding 
about  just  how  powerful  LQS  can  be  for  engine  control  design.  LQS  determines  a 
set  of  feedback  gains  to  provide  good  regulation  and  small  perturbation  response  about 
a specified  set  point.  It  does  not  define  how  to  schedule  these  set  points  either 
in  the  steady  or  transient  state.  Thus,  during  a gross  transient,  the  LQS  derived 
control  mode  regulates  to  these  transient  set  points,  but  it  is  really  the  transient 
motion  of  these  set  points  that  determines  the  gross  transient  performance.  Some 
other  technique,  such  as  the  nonlinear  trajectory  optimization  technique  must  be  used 
to  determine  how  best  to  move  these  set  points  to  obtain  the  desired  gross  transient 
performance. 

Because  this  technique  was  in  its  infancy,  it  was  not  applied  to  design  of  the  IPCS  control 
mode.  Since  that  time,  however,  studies  of  application  of  this  technique  to  other 
propulsion  systems  have  established  confidence  in  the  linear  quadratic  synthesis 
technique  as  an  efficient  design  tool  to  be  included  as  an  important  element  of  the 
overall  control  design  process. 
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5.0  SOFTWARE  DEVELOPMENT 

5.1  DEVELOPMENT  PROCESS 

The  IPCS  software  development  process  proceeded  in  an  orderly  and  systematic  manner 
through  the  establishment  and  maintenance  of  design  specifications.  The  functional 
interface  and  performance  requirements  were  established  in  the  form  of  a Design 
Specification,  Part  I (see  paragraph  5.2).  That  document  establishes  the  design 
requirements  baseline  for  the  design  and  qualification  testing  of  each  computer 
program.  The  preliminary  and  detailed  design  are  documented  via  the  preparation  of  a 
Design  Specification,  Part  II.  That  document  contains  narrative  and  graphical 
information  describing  the  computer  program  information  and  process  flow. 

The  development  process  was  initiated  by  defining  the  program's  functional  interface  and 
performance  requirements  in  the  Part  I specification.  Subsequently,  the  design  proceeded 
in  two  phases;  the  preliminary  design  and  the  detailed  design  phases. 

During  the  preliminary  design  phase,  the  individual  computer  program  components  (CPCs) 
were  identified.  The  various  functional  requirements  set  forth  in  the  Part  I specification 
were  then  allocated  among  the  CPCs.  The  CPCs  were  selected  based  upon  the  similarity 
of  the  BOMDIG  and  IPCS  requirements  such  that  must  of  the  design  and  code  developed  for 
BOMDIG  could  also  be  applied  to  IPCS.  Four  CPCs  were  identified.  Executive  CPC,  Sensor 
Processing  CPC,  Output  Processing  CPC,  and  Control  CPC.  The  first  three  remain  essentially 
unchanged  between  the  two  programs.  The  Control  CPC,  which  provides  the  control 
algorithms,  is,  of  course,  significantly  different.  This  approach  is  recommended  even 
if  only  one  set  of  control  laws  is  being  developed.  Isolation  of  the  control  law 
permits  deferral  of  control  law  implementation  until  the  design,  code  and  debug  of  the 
other  functions  are  completed,  permitting  additional  time  for  control  law  refinement 
and  cost  effective  update  of  the  control  algorithms  through  the  various  test  phases. 

A preliminary  design  review  was  conducted  subsequent  to  completion  of  preliminary  design. 
Due  to  the  time  available  and  the  make-up  of  the  design  review  audience,  the  review 
consisted  of  a presentation  to  show  evidence  of  technical  progress  rather  than  a review 
as  such.  Although  this,  in  retrospect,  proved  acceptable  due  to  the  R&D  nature  of  the 
program,  a more  detailed  investigation  would  seem  appropriate  for  a production  config- 
uration. 

Subsequent  to  preliminary  design,  the  detailed  design  phase  was  entered.  The  Part  II 
specification  was  completed  during  this  phase  providing  a detailed  description  of 
the  computer  program  data  base  and  a detailed  description  of  each  CPC  including 
information  and  process  flow.  This  information  was  provided  to  the  level  of  detail 
to  commence  coding. 

Test  procedures  were  also  prepared  during  this  period.  The  procedures  were  divided  into 
three  categories.  The  first  of  these  focused  attention  on  those  requirements  which 
could  be  verified  on  a stand-al  ne  computer  facility  without  flight  hardware.  The 
second  focused  attention  on  those  requirements  which  could  be  verified  only  using  the 
flight  hardware.  The  last  category  involved  use  of  the  flight  hardware  and  propulsion 
module  simulation  and  exercised  the  software  over  a pre-defined  set  of  flight 
conditions.  The  first  two  categories  proved  useful  during  software  debug,  even  though 
the  schedule  did  not  permit  completion  of  all  the  planned  tests.  In  general,  features 
such  as  schedules  and  compensation  networks  should  be  evaluated  in  open-loop  tests. 

It  is  recommended  that  other  verification  be  performed  exclusively  with  the  controller 
hardware  and  ground-support  equipment. 

A critical  design  review  was  conducted  subsequent  to  completion  of  detailed  design. 

This  review  was  similar  to  the  preliminary  design  review  and  the  same  remarks  apply. 

The  programming  phase  consisted  of  three  activities;  namely,  coding,  informal  testing 
(often  referred  to  as  debug)  and  CPC  integration. 

Finally,  the  verification  test  phase  was  entered  and  completed  prior  to  the  beginning 
of  bench  tests. 
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5.2  SOFTWARE  CONFIGURATION  CONTROL 


Proper  configuration  management  and  control  is  an  essential  element  in  the  successful 
pursuit  of  any  computer  program  design  and  development  effort.  Without  proper  control, 
software  flexibility  can  destroy  what  might  otherwise  be  a well-managed  effort.  On 
the  other  hand,  the  change  procedure  must  not  be  so  ponderous  that  it  is  an  unnecessary 
burden. 

During  software  development,  the  specifications  were  placed  under  the  direct  control  of 
the  software  project  engineer.  Prior  to  verification  testing,  the  specifications  and 
the  computer  programs  were  released  to  the  configuration  control  of  the  technical 
Program  Manager.  Release  of  the  computer  program  listing  is  a necessary  pre-requisite 
for  verification  testing. 

5.3  DOCUMENTATION  OF  REQUIREMENTS 

Software  design-to  and  test-to  requirements  are  delineated  in  two  specifications;  one 
for  each  of  the  programs,  BOMDIG  and  IPCS.  These  specifications  have  a format  and 
content  compatible  with  MIl-STD-583.  These  specifications  were  prepared  using  a 
magnetic  tape  system  which  significantly  reduced  the  clerical  effort  and  turn-around 
time  for  specification  change  updates. 

The  Information  contained  in  these  specifications  was  obtained  from  several  sources 
since  the  requirements  imposed  on  software  typically  arise  from  several  sources.  The 
control  algorithms  were  taken  largely  from  the  Boeing/Honeywell  ICD  supplemented, 
when  necessary,  by  coordination  memos.  Detail  information  concerning  the  interface 
between  the  software  and  the  DCU,  IFU,  sensors,  actuators,  etc.  was  taken  largely  from 
Honeywell  hardware  specifications  being  prepared  in  parallel.  Preparation,  release  to 
configuration  control  and  maintenance  of  these  two  specifications,  their  format  and 
their  content  served  this  program  well  and  are  recommended  for  other  programs.  One 
improvement  would  have  been  to  include  the  block  diagrams  describing  the  IPCS  control 
laws  in  the  IPCS  software  specification  in  addition  to  the  control  equations.  A 
FORTRAN  listing  of  the  control  laws  programmed  for  the  digital  simulation  as  discussed 
in  Section  4.2.1  is  an  acceptable  means  of  documenting  the  control  equations. 

The  control  algorithms  for  BOMDIG  were  described  in  the  ICD  via  block  diagrams.  The 
control  algorithms  for  IPCS  were  described  via  block  diagrams  and  via  a sequence  of 
FORTRAN  statements.  Those  FORTRAN  statements  and  their  sequence  were  obtained  as  a 
by-product  of  the  algorithm  development  activity. 

Block  diagrams  represent  an  analog  model  of  a physical  system  in  which  processes  are 
carried  out  over  a continuum  in  parallel  with  other  processes.  This  model  must  then 
be  translated  into  a digital  model  (flow  chart)  in  which  the  processes  are  carried  out 
within  a discrete  set  and  in  a specific  sequence.  That  translation  is  not  one-to-one 
and  there  exists  the  attendant  risk  of  increased  cost  and  schedule  to  obtain  a digital 
model  having  acceptable  performance  characteristics. 

The  IPCS  control  was  defined  using  both  models.  The  digital  model  was  used  directly 
to  establish  the  software  requirements.  The  analog  model  served  to  clarify  the  operations 
being  performed  and  provide  insight  into  dynamic  behavior  necessary  to  establish 
digital  scale  factors  and  debug  and  test  the  software  subsequent  to  coding. 


The  use  of  the  digital  model  to  define  the  control  algorithms  permits  a lonqer 
algorithm  development  period  since  the  time  required  subsequently  to  code  and  test  the 
digital  model  is  considerably  less  than  that  for  an  analog  model.  Definition  of  the 
digital  model  in  FORTRAN  is  not  necessary,  but  the  language  should  be  one  widely 
known  and/or  easily  readable  and  understandable  without  ambiguities. 

Ideally,  the  control  law  algorithms  should  be  developed  communicated  and  controller- 
implemented  in  a high-order  language  easily  understood  by  all  personnel  involved  in 
controller  development.  The  choice  of  language  is  difficult.  The  language  should  be 
one  which  can  be  efficiently  implemented  in  the  controller  computer  (including  ROM 
configurations)  to  reduce  recurring  costs  and  should  provide  for  word  length  and  process 
time  adjustments  when  run  on  the  algorithm  development  computer  facility.  These  require- 
ments immediately  rule  out  the  use  of  FORTRAN.  The  choice  will  typically  Involve  some 
level  of  compiler  and/or  language  development  depending  upon  the  state-of-the-art  and/or 
availability  of  compilers  existing  at  the  time  the  decision  must  be  made  in  order  to  obtain 
a timely  analysis  of  cost  effectiveness. 
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If  such  a language  is  not  or  cannot  be  made  available,  the  approach  used  on  1 PCS  is 
recommended;  FORTRAN  as  a development  and  communication  language  and  assembly  language 
for  controller  implementation. 

5.4  RESOURCE  UTILIZATION 

5.4.1  Memory  Size  and  Process  Time 

The  initial  concepts  of  the  control  algorithms  and  implementation  were  used  to  establish 
initial  estimates  of  the  memory  size  and  process  time  required.  These  initial  estimates 
were  low,  but  enough  capacity  had  been  provided  to  meet  all  program  goals. 

The  initial  low  estimates  were  without  significant  penalty  only  because  the  hardware 
design  was  based  upon  a recognition  of  the  R&D  nature  of  the  program.  The  primary 
benefiting  factors  were  a full  16K  of  memory  and  the  5 msec  sample  interrupt  design 
(which  permitted  a later  necessary  50%  extension  of  the  IPCS  sample  period).  Had  this 
been  a production  program  with  the  attendant  emphasis  on  recurring  per-unit  costs,  the 
requirement  to  match  computer  capability  to  system  requirements  would  be  much  more 
stringent.  About  six  months  into  the  program,  the  control  laws  were  sufficiently 
defined  and  the  hardware  design  was  sufficiently  far  along  to  warrant  a new  estimate. 

At  this  point,  the  inadequacy  of  the  initial  concept  became  apparent.  As  a result  the 
emphasis  of  software  design  switched  from  conservation  of  both  resources  to  that  of 
process  time  alone  and  the  sample  interval  for  IPCS  was  increased  from  20  to  30 
mill iseconds. 

Subsequently,  software  design  concentrated  on  the  development  of  the  BOMDIG  program  (which 
is  identical  to  the  IPCS  program  except  for  the  control  laws  and  the  difference  in 
sample  period)  while  the  analysts  concentrated  on  refining  the  IPCS  control  laws  for 
later  implementation  in  software.  Near  the  end  of  this  period,  that  is,  once  the  final 
control  algorithms  were  selected,  the  resource  requiements  for  IPCS  were  again  estimated. 

The  result  was  tha  a concentrated  effort  was  necessary  to  condense  the  control  laws, 
primarily  in  the  number  of  data  points  used  to  describe  the  various  univariate  and  bi- 
variate functions  This  effort  was  successful  and  over  a thousand  data  points  were 
deleted  without  adverse  effect  on  control  performance. 

The  impact  on  cost  and  schedule  would  have  been  significant  if  the  reduction  could  not 
have  been  achieved  without  basic  modifications  of  the  then-existing  control  concepts. 

Control  designers  must  keep  in  mind  that  the  control  must  not  only  be  physically  realizable, 
but  must  be  realizable  within  the  resources  available.  It  is  recommended  that  memory 
size  and  process  time  be  more  frequently  projected  with  budgets  established  for  growth 
during  bench,  SLS,  altitude  and  flight  tests.  Furthermore,  these  projections  should  be 
closely  monitored  to  the  extent  that  potential  problems  can  be  identified  and  resolved 
before  they  can  cause  cost/schedule  impact. 

5.4.2  Word  Length 

The  dynamic  range  and  precision  6f  control  variables  within  the  digital  computer  are 
limited  by  the  computer  word  length.  A cursory  analysis,  prior  to  selection  of  the  HDC- 
601,  indicated  that  a 16  bit  word  length  would  be  sufficient.  The  double-precision 
(31  bits)  arithmetic  available  in  the  HDC-601  could  be  used  to  gain  additional  range 
or  precision  is  necessary.  It  proved  to  be  unnecessary  except  in  the  gas  generator 
fuel  command  (isochronous  governor)  integrator. 

Care  was  taken  during  the  detailed  software  design  to  scale  all  data,  using  fixed-point 
binary  scale  factors,  to  achieve  maximum  precision  based  solely  upon  needed  range 
(maximum  magnitude  expected).  Problems  were  expected  since  the  control  laws  were 
being  developed  in  parallel  using  FORTRAN  having  significantly  greater  precision  and, 
for  all  practical  purposes,  infinite  range. 

Only  one  problem  was  encountered.  Control  law  analysts  specified  large  constant  values 
in  the  IPCS  loop  select  logic  which  gave  rise  to  an  Inability  to  select  the  proper  loop 
due  to  insufficient  precision.  However  the  large  constants  were  in  fact  arbitary  and 
were  subsequently  rescaled  (from  10,000  to  31,  for  example)  to  accommodate  both  range 
and  precision  within  the  16  bit  word. 
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5.5  SOFTWARE  TESTING 


Software  testing  proceeded  in  three  phases  as  follows: 

1)  Informal  or  debug  phase 

2)  Verification  phase 

3)  Category  II  test  phase 

The  informal  or  debug  phase  was  the  last  step  in  the  software  implementation  process  to 
prepare  the  software  for  verification.  The  software  was  not  under  configuration  control 
during  debug  to  facilitate  handling  the  large  number  of  anticipated  changes  in  a cost 
effective  manner. 


However,  the  software  was  placed  under  configuration  control  during  verification  testing. 
This  was  necessary  since  it  is  the  intent  of  verification  testing  to  establish  assurance 
that  the  software  being  delivered  meets  its  requirements.  Hence,  the  configuration  must 
be  identified  and  controlled  so  to  relate  the  configuration(s)  tested  to  that  delivered. 

As  indicated  in  paragraph  5.1,  the  verification  tests  for  BOMDIG  and  IPCS  were  divided 
into  three  categories.  This  division  was  made  with  the  thought  that  some  verification 
could  be  performed  prior  to  the  availability  of  the  flight  hardware.  In  retrospect, 
this  was  not  cost  effective  and  did  not  contribute  to  an  intended  schedule  pull-in.  It 
is  recommended  that  verification  testing  be  performed  exclusively  with  flight  hardware 
and  ground  support  equipment  with  all  closed-loop  control  performance  testing  performed 
against  a real-time  dynamic  simulation  of  the  propulsion  module. 

Verification  testing  included  control  of  the  simulated  propulsion  module  at  various  flight 
conditions.  Key  simulation  performance  parameters  were  recorded  on  a graphic  plotter  and 
compared  against  those  recorded  earlier  using  a FORTRAN  control  algorithm  model  at  the 
same  conditions.  This  proved  extremely  beneficial  since  it  afforded  performance 
verification  in  a closed-loop  dynamic  environment  closely  simulating  the  expected  flight 
environment.  It  is  recommended  that  this  type  of  testing  be  the  main  thrust  of  future 
verification  efforts  supplemented  by  specific  open-loop  tests  for  those  functions  for 
which  the  simulation  does  not  provide  an  acceptable  environment. 

The  bench  tests  at  East  Hartford  provided  further  software  verification  implicit  in  the 
system  level  test.  Indeed,  the  bench  tests  did  provide  an  environment  different  than 
that  provided  by  the  hybrid  simulation. 

Due  to  the  lack  of  time  between  the  availability  of  the  flight  hardware  and  its  shipment 
for  bench  tests,  software  verification  focused  primarily  on  those  functions  for  which 
the  simulation  was  best  suited.  As  a consequence,  some  problems  remained  to  be  un- 
covered during  bench  test.  Some  level  of  dependence  on  the  use  of  the  bench  test 
facility  for  software  verification  seems  appropriate  as  will  be  discussed  in  Section  7.0 
of  this  document. 


5.6  FIELD  SUPPORT 


Except  for  two  or  three  errors  uncovered  during  the  early  bench  testing,  all  software 
field  changes  reflected  changes  in  software  requirements.  This  was  not  unusual  and 
can  be  expected.  The  flexibility  afforded  by  a digital  system  is  clearly  a significant 
factor  in  the  cost-effective  development  of  a controller  for  either  a new  or  existing 
engine. 

On  IPCS,  changes  subsequent  to  delivery  for  bench  tests  were  introduced  via  patches  to 
the  software.  The  computer  programs  were  then  updated  at  Honeywell  and  new  program 
tapes  incorporating  these  changes  were  shipped.  New  tapes  were  not  prepared  on  a 
frequent  basis  (flight  tests  were  performed  using  only  the  third  revision  of  the 
original  IPCS  tape)  and  each  revision  involved  literally  hundreds  of  requirement 
changes.  Honeywell  had  no  in-house  facility  for  verifying  the  changes.  Such  facilities 
must  be  available  to  support  a production  program. 


Although  the  sequence  of  bench,  SLS  altitude  and  flight  test  progressed  on  schedule  with 
technical  success,  the  software  requirement  change  process  warrants  improvement  to  reduce 
the  risk  of  test  schedule  impact.  Updates  should  be  done  more  frequently.  Patches  should 
be  limited  to  those  changes  required  to  maintain  the  test  schedule.  The  first  three  major 
tests  after  software  delivery  - bench  test,  sea-level  test,  and  altitude  test  - were,  for 
most  part,  two-shift  operations  that  were  supported  on-site  by  one  software  engineer. 

This  one  engineer  supported  both  test  shifts  as  well  as  designing,  implementing,  and 
documenting  all  required  software  changes.  As  a result,  some  mistakes  were  unavoidable 
and  the  attendant  documentation  was  clearly  inadequate.  It  is  recommended  that  future 
test  programs  be  supported  by  at  least  one  software  engineer  to  support  test  operations 
and  one  experienced  individual  at  the  test  site  who  is  responsible  only  for  software  design 
changes  and  maintenance  of  documentation.  At  appropriate  intervals,  new  tapes,  incorpor- 
ating all  changes  made  since  the  last  formal  revision  would  be  issued  by  the  control 
vendor.  These  new  revisions  would  be  subject  to  some  level  of  verification  testing 
using  a flight  hardware  configuration  and  propulsion  model  simulation  prior  to  shipment 
to  the  test  site.  In  addition,  the  test  set  unit  (TSU)  should  have  the  capability  to 
close  the  control  loop  for  software  checkout  in  the  field. 

5.7  SOFTWARE  DEVELOPMENT  FOR  ROM 

The  use  of  Read  Only  Memory  (ROM)  within  the  controller  presents  no  problems  in  the 
software  development  process  provided  the  two  considerations  addressed  below  are  observed. 

Although  the  IPCS  experience  did  not  include  the  use  of  ROM,  the  recommendation,  herein 
is  based  upon  Honeywell  experience  on  other  programs.  This  experience  encompasses 
successful  production  programs,  both  commercial  (digital  air  data  system)  and  military 
(helmet  sight)  and  numerous  R&D  and  demonstration  programs. 

A necessary  condition  to  achieve  a successful  ROM  program  is  to  use  alterable  memory 
during  development  and  the  initial  phases  of  controller  testing.  Honeywell  uses 
commercial,  off-the-shelf,  electrically  alterable  (RAM)  memory.  These  are  interfaced 
to  the  flight  computer  in  a manner  which  is  both  electrically  and  physically  (except 
for  size  and  power  requirements)  identical  to  the  ROM  interface.  This  configuration 
is  used  during  software  debug  and  verification  and  sbusequent  system  level  tests 
whenever  the  environment  permits.  Honeywell  has  used  commercial  memory  during  flight 
test  where  safety-of-fl ight  has  not  been  a factor.  The  number  of  alterable  configurations 
available,  usually  *wo  or  more,  is  a function  of  the  number  of  simultaneous  test  and 
support  activities  in  progress. 

The  recommended  transition  from  RAM  to  read-only  memory  is  during  the  last  phase  of 
ground  based  tests  just  prior  to  flight  tests.  This  would  permit  maximum  flexibility 
during  all  phases  of  pre-flight  test  while  permitting  sufficient  lead  time  for  ROM 
fabrication.  The  transition  can,  of  course,  be  delayed  if  the  alterable  memory 
configuration  is  one  which  is  flightworthy. 

The  second  necessary  condition  to  achieve  a successful  ROM  program  is  to  develop  the 
software,  beginning  at  the  initial  setting  of  requirements,  to  operate  in  the  ROM 
configuration.  In  general,  software  developed  without  this  goal  in  mind  will  not 
function  in  a ROM  environment  without  extensive  modification.  If  the  controller 
software  is  developed  in  an  assembly  language,  the  separation  of  variables  and 
constants  according  to  the  RAM/ROM  configurations  does  not  increase  complexity  or  add 
to  cost  and  schedule  if  (and  only  if)  that  separation  is  initiated  at  the  onset. 

The  same  is  true  if  a high-order  language  is  used  provided  that  language  supports 
the  use  of  ROM  and  the  compiler  can  generate  code  compatible  with  the  specific 
configuration.  If  not,  some  level  of  cost  and/or  schedule  penalty  is  likely. 
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6.0  HARDWARE  DEVELOPMENT 


Hardware  development  covers  the  specification,  design,  procurement  and/or  fabrication, 
and  flight  assurance  testing  of  components  and  subsystems  that  meet  the  requirements 
discussed  in  Section  3.0.  The  iterat  ve  nature  of  a development  program  will  be 
especially  evident  in  the  hardware  area.  It  is  commonly  found  that  the  components 
needed  to  meet  specific  requirements  are  unavailable,  impossible  with  existing  technology, 
or  are  more  expensive  than  anticipated.  The  requirements  must  be  reassessed  and 
the  options  weighed.  Hopefully  the  requirements  can  be  relaxed.  Otherwise  the  extra 
cost,  weight,  space,  or  environmental  protection  burden  must  be  assumed.  If  this  is 
unfeasible  it  may  be  necessary  to  redesign  the  control  algorithm  to  eliminate  the 
offending  component.  A program  to  generate  new  component  technology  should  be  attempted 
only  as  a last  resort. 

It  is  of  course  imperative  that  hardware  requirements  not  be  changed  unilaterally.  In 
a closely  integrated  system,  the  impact  of  a single  change  can  propagate  through  the 
entire  system. 

6.1  ENGINE  RELATED  COMPONENTS 

For  either  an  R&D  type  program  or  a production  type  new  engine  program,  certain  require- 
ments should  be  established  during  the  Preliminary  Design  Phase  of  the  program  to  aid  in 
the  development  trade  studies  to  permit  selection  of  the  hardware.  These  requirements 
are  as  follows: 

1.  Accuracy,  Response,  and  Resolution 

2.  Reliability,  and  Maintainability 

3.  Flexibility 

4.  Cost 

5.  Schedule  (procurement  and  development  time) 

6.  Weight  and  Volume 

Each  one  of  these  requirements  must  be  assigned  a weighting  function  to  permit  the  design 
engineer  to  evaluate  those  factors  most  important  to  his  program.  The  criteria  used  to 
select  hardware  may  be  weighted  to  provide  accuracy,  response  and  resolution  for 
the  control  mode,  while  maintaining  maximum  reliability.  This  would  be  done  by  using 
"existing"  developed  hardware  with  minimum  engine  plumbing  and  modification  changes. 

This  approach  would  probably  suffer  in  flexibility,  weight  and  volume,  as  these 
factors  become  secondary  considerations. 

When  it  is  necessary  to  develop  new  hardware  rather  than  to  use  existing  components, 
this  requirement  should  be  identified  during  the  study  phase  of  the  program  to  allow 
for  development  time  of  the  individual  component.  It  is  equally  important  that  if  a 
newly  developed  component  is  to  be  used,  that  a reliable  functional  backup 
be  provided. 

In  the  IPCS  program,  reliability  and  accuracy  were  the  dominant  criteria,  and  a backup 
or  synthesis  was  provided  for  all  items  considered  to  be  at  the  newest  level  of  desiqn 
or  proven  performance.  For  example,  the  TIGT  fluidic  sensor  system  was  new  to  the  TF30-P-9 
engine.  As  a backup  the  software  was  configured  to  synthesize  the  turbine  inlet 
temperature  signal.  As  it  turned  cut,  the  TIGT  sensor  could  not  be  installed  in  one 
of  the  engines  due  to  a modification  problem.  The  impact  of  this  was  minimized  because 
the  T4  signal  synthesis  was  available  as  alternative  source  of  the  temperature  signal. 

The  following  subsections  will  discuss  the  criteria  for  hardware  selection  and  how  they 
could  be  applied  to  other  programs. 

6.1.1  Transducer  Selection 

Sensor  selection  is  critical  to  any  propulsion  control  system.  The  accuracy  and 
^eponse  of  each  sensor  may  have  a major  impact  on  the  accuracy  and  dynamic  characteristics 
‘ the  related  control  loops.  Engine  parameters  vary  over  a wide  range  throughout  the 
' ;ht  envelope;  thus  the  control  sensors  selected  must  be  capable  of  maintaining 
• eptatiie  accuracy  with  a considerable  turndown  ratio  (maximum  value/minimum  value). 

- ne  nacelle  Is  a hostile  environment  that  exposes  transducers  to  variations  in 
■ a'jre  and  to  vibration  that  will  reduce  their  useful  life  if  they  are  not  protected. 
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The  approach  to  transducer  selection  starts  with  establishment  of  performance  requirements. 
The  next  step  is  to  review  existing  hardware  to  determine  if  proven  components  can  be  used. 
Two  types  of  errors,  steady  state  and  dynamic  (or  transient),  must  be  considered.  Steady- 
state  errors  can  be  reduced  by  calibration  if  they  are  repeatable,  as  in  the  case  of  non- 
linearity, or  if  they  can  be  related  to  environment,  as  in  the  case  of  thermal  shift  of  a 
pressure  transducer.  Dynamic  errors  can  be  compensated  if  they  are  predictable  and  not 
excessive.  Typical  sensing  devices  exhibit  a constant  incremental  error  throughout 
their  operating  range,  and  the  major  impact  on  system  accuracy  occurs  at  the  low  end  of 
the  operating  range  when  the  error  becomes  a large  percentage  of  the  measured  value. 

The  locations  of  the  sensors  are  usually  determined  by  a configuration  trade  study  that 
considers  factors  such  as  performance,  cost,  weight,  and  reliability.  The  outcome  of 
such  a study  may  indicate  that  the  sensors  should  be  located  on  the  engine  to  minimize 
pneumatic  line  lengths  for  best  transient  accuracy.  This  outcome  satisfies  the 
performance  requirements.  However  the  transducers  may  not  be  designed  to  tolerate  the 
engine  environment.  If  the  configuration  studies  require  the  electronic  control  to  be 
on  the  engine,  the  transducers  may  be  packaged  with  the  control,  assuming  that  it  is 
environmentally  protected.  If  the  control  is  mounted  off  the  engine,  separate  environ- 
mental protection  may  be  required  for  the  transducers.  An  approach  that  may  be 
selected  to  minimize  transducer  changes  with  environment  and  improve  reliability  is 
to  package  all  sensors  into  a common  cooled,  insulated  package. 

The  IPCS  program  considered  both  the  strain-gage  and  vibrating  cylinder  pressure 
transducers  for  pressure  measurement  with  the  strain-gage  type  being  selected  for 
the  engine.  The  strain-gage  type  was  sufficiently  accurate  for  the  IPCS  control 
loops  and  previous  test  experience  had  demonstrated  their  reliability. 

The  transducer  box  for  the  IPCS  program  had  difficulty  with  braze  welds  that  did  not 
cover  the  required  area,  as  detected  by  X-Ray  measurements  after  vibration  testing. 

The  alternative  was  to  eliminate  fuel  cooling,  fill  the  box  with  silicone  oil  and 
rely  on  the  insulation  blanket  for  the  required  environmental  protection.  This 
approach  was  acceptable  for  the  IPCS  mission  because  of  the  limited  time  of  exposure  to 
high  temperatures. 

6.1.2  Gas  Path  Probes 

The  guidelines  for  gas  path  temperature  and  pressure  probe  selection  are  as  follows: 

1.  Define  signals  that  are  required  to  control  the  engine. 

2.  Establish  a priority  of  these  measurements  as  to  their  impact 
on  engine  control. 

3.  Determine  accuracy  and  number  of  probes  required. 

4.  Assess  the  impact  of  these  measurements  on  engine  design  or 
modification,  structural  impact  to  engine,  and  effect  on  engine 
schedule,  cost,  weight,  maintainability,  and  reliability. 

Probe  design  trade  studies  must  be  conducted  to  define  such  factors  as  probe  configuration, 
location  (axial,  radial),  and  the  number  of  probes  required  for  obtaining  consistent 
and  repeats ble  measurements.  Information  to  support  these  studies  is  obtained  from 
analytical  studies,  rig  testing  and  past  engine  experience. 

The  approach  used  in  the  IPCS  program  was  to  identify  the  probes  required  from  the 
component  requirements  chart  shown  as  Figure  3.1-1.  Each  measurement  was  evaluated  to 
assess  its  impact  on  engine  modification  and  probe  development.  All  efforts  were  made 
to  minimize  the  number  of  measurements  required.  This  was  accomplished  by  reworking 
the  control  mode  algorithm  to  an  acceptable  configuration  with  a minimum  number  of 
measurements  by  using  parameter  substitution  or  signal  synthesis.  Only  those 
signals  determined  to  be  critical  for  control  were  retained. 

The  basis  for  selection  of  gas  path  pressure  probe  design  for  the  IPCS  program  was  to 
meet  the  mode  requirements  while  maintaining  a high  level  of  reliability.  This  was 
done  by  selecting  proven  reliable  probe  designs  which  had  been  used  in  previous 
programs.  The  same  was  true  for  temperature  probes,  where  TF30  Bill-of-Material 
probes  were  retained. 
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6.1.3  Output  Interfaces 

The  first  step  in  selecting  the  output  interface  for  a digital  electronic  control  is  to 
perform  a trade  study  to  identify  the  optimum  approach  for  the  application.  The  trade 
study  must  consider  the  following:  steady  state  accuracy,  transient  response,  reliability, 

maintainability,  cost,  weight,  and  size.  Data  from  actual  design  and  test  experience,  and 
requirements  of  the  engine  will  provide  the  baseline  for  selection  of  candidate  interface 
devices. 

In  the  IPCS  program,  the  output  interfaces  were  selected  by  using  the  devices  that  most 
conveniently  interfaced  with  existing  hardware.  A torque  motor  servo  stage  was  selected 
to  position  the  metering  valve  of  the  main  fuel  control  upon  command  from  the  digital 
computer.  Stepper  motors  were  selected  to  control  the  zone  metering  valves  and  exhaust 
nozzle  servo  in  the  afterburner  and  exhaust  nozzle  control.  In  both  systems  resolvers 
were  used  to  feed  back  the  position  of  the  valves. 

The  torque  motor  and  stepper  motors  were  selected  for  the  different  applications  because 
each  addressed  the  available  hydraulic  interfaces  in  the  most  reasonable  manner.  Both 
components  had  been  used  in  similar  flight  applications  and  were,  therefore,  proven 
designs  which  increased  the  reliability  of  the  system.  The  results  of  the  IPCS 
tests  indicated  that  the  torque  motor  and  stepper  motors  did  in  fact  meet  the  accuracy 
and  response  requirements  of  the  IPCS  control  modes. 

6.2  INLET  AND  AIRFRAME  RELATED  COMPONENTS 

Most  of  the  hardware  developed  for  propulsion  control  by  the  airframe  manufacturer  will 
be  used  in  installing  purchased  components  or  equipment  supplied  by  the  controls  or 
engine  manufacturer.  This  includes  mounts,  environmental  protection,  and  aircraft 
wiring.  Some  pressure  probes  may  also  be  fabricated  by  the  airframe  manufacturer.  The 
comments  below  are  based  upon  IPCS  experience  in  these  areas. 

6.2.1  Manufacturing  Techniques  and  Procedures 

The  "red-line"  drawing  system  lends  itself  readily  to  research  and  development  programs, 
where  oniy  a small  number  of  parts  are  to  be  produced.  This  allows  the  fabrication 
of  the  part  to  proceed  without  extensive  drawing  revision  due  to  changes  required  during 
the  manufacturing  sequence.  These  changes  are  maintained  in  red-line  form  on  a "master- 
drawing" and  not  incorporated  in  the  original  until  the  part  is  completed,  has  passed 
Flight  Assurance  Testing  and  is  ready  for  QC  approval.  This  approach  saves  much  time 
during  the  development  of  new  parts. 

Materials  technology  groups  should  be  consulted,  early  in  the  preliminary  design  phase, 
for  feasibility  studies  if  special  techniques  are  being  considered.  Parts  requiring 
special  techniques  such  as  critical  welds  should  be  avoided  unless  ample  time  is 
allowed  to  develop  the  technique. 

6.2.2  Modi' ication  of  Aircraft  Structure 

It  is  mandatory  that  structural  drawings  and  cognizant  personnel  be  available  if 
changes  are  required  to  the  aircraft  structure.  If  drawings  from  outside  the  company 
are  required,  arrangements  must  be  made  to  make  them  available  on  an  easy  and  rapid 
basis.  Approval  of  structural  changes  should  be  obtained  from  the  design  group  that 
did  the  original  design.  Before  initiating  any  changes  much  can  be  gained  by 
discussing  the  proposed  changes  with  the  originating  design  group.  Budget  will  have 
to  be  provided  for  this  within  the  company.  If  the  original  design  was  done 
outside  the  company,  a sub-contract  for  these  services  will  probably  be  required. 

6.2.3  Wiring 

Wiring  techniques  will  vary  between  research  and  production  type  programs.  During  "one 
time  only"  research  programs,  wire  bundles  can  be  fabricated  and  routed  on  installation. 
Clamping  can  be  accompl ished  using  existing  structure  to  clamp  to.  Special  shielding 
can  be  avoided  through  the  use  of  Zip  On  Shielding.  Special  wire  and  connectors  should 
be  avoided  because  of  problems  of  availability  and  cost. 
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6.3  CONTROLLER  DEVELOPMENT 


The  development  of  the  controller  hardware  should  be  performed  concurrently  with  the 
development  of  the  engine.  An  electronics  system  engineer  should  be  available  to 
perform  trade  studies  in  conjunction  with  the  engine  designers.  System  level  studies 
to  optimize  the  electronics  environment  would  be  performed  during  this  period  of 
development. 

A chronological  plan  to  be  applied  in  the  development  of  a controller  for  future 
propulsion  control  systems  is  presented  here.  Discussions  provided  in  each  development 
area  discussing  tradeoffs  and/or  providing  recommendations  are  based  on  the 
experience  gained  during  the  IPCS  program.  The  discussions  are  organized  chronologically: 

1.  System  studies  and  recommendations 

2.  Controller  specifications,  design,  fabrication,  and  test 

The  initial  system  tradeoff  studies  and  recommendations  constitute  the  major  portion  of 
the  following  dissertation.  Specification,  hardware/software  design,  fabrication,  and 
testing  discussions  relate  to  the  relatively  conventional  procedures  for  development  of 
a control  system. 

6.3.1  System  Studies  and  Recommendations 

6. 3. 1.1  On  vs  Off  Engine  Mounting  of  Electronics  (Controller  Company  Viewpoint) 

The  IPCS  Digital  Propulsion  Control  Unit  (DPCU)  Controller  was  shock  mounted  in  the 
weapons  bay  of  the  F-lll.  The  aircraft  environmental  control  system  (ECS)  provided 
cooling  air.  This  off-engine  special  mounting  was  selected  to  enhance  the  reliability 
of  this  R&D  controller.  The  off-engine  environment  provided  a relatively  easy,  low-cost 
and  low-risk  design. 

In  the  consideration  of  a production  engine  controller,  however,  there  are  some  dis- 
advantages to  an  off -engine  mounting: 

a.  Controller  is  not  an  integral  part  of  the  engine. 

b.  Long  heavy  cabling  may  be  necessary. 

c.  Special  airframe  mount,  with  shock  mounting  and  cooling,  is  needed. 

If  an  engine  mounting  can  be  designed  such  that  comparable  shock  mounting  and  cooling 
is -provided  on  engine,  the  controller  can  be  an  integral  part  of  the  engine  and  long 
heavy  cabling  will  be  not  required.  The  on  vs  off  engine  mounting  then  becomes  a 
question  of  whether  the  engine  can  be  designed  to  provide  a controlled  environment 
for  the  controller,  and  what  the  penalty  of  this  is  in  comparison  to  cabling  penalties, 
etc.  of  off-engine  mounting. 

Off  engine  mounting  is  completely  practical  as  demonstrated  by  IPCS  and  can  be  implemented 
with  conventional  electronic  assemblies.  The  hardware  will,  of  course,  be  state-of-the- 
art,  and  consequently  much  smaller  and  require  less  power  than  IPCS,  which  makes  off- 
engine  mounting  even  more  viable.  There  are  three  possible  off-engine  configurations: 

1.  Near  to  Engine  (3  to  8 feet)  such  that  pressure  probe  pneumatic 
lines  can  be  run  directly  from  controller  to  engine.  This  close- 
to-the-engine  configuration,  will  hopefully  provide  an  environ- 
ment that  is  easily  controlled  to  ensure  the  standard  avionics 
electronic  environment.  A recent  study  indicates  that  the 
close-to-engine  environment  is  not  always  greatly  improved  over 
the  engine  environment.  This  approach  would  have  to  be  reviewed 
for  each  new  airframe  installation  and  would  impose  reoccurring 
costs  for  each  installation.  For  these  reasons  a close-to-engine 
mount  may  have  no  significant  advantage  over  the  on-engine  mount. 


2.  Farther  away  from  the  Engine  (8  to  20  feet)  such  that  the  pressure 
and  temperature  transducers  must  be  mounted  on-engine  in  a transducer 
box.  This  configuration  is  equivalent  to  IPCS,  and  is  therefore  a 
proven  method.  The  disadvantages,  however,  are  the  cable  weight  and 
special  mounting  required  for  each  new  airframe  installation.  If 
the  weight  of  cable  and  special  mounting  requirements  (to  guarantee 

a conventional  avionics  electronics  environment)  can  be  obtained  at 
a lower  cost  per  airframe  than  on-engine,  this  approach  is  preferred. 

3.  A great  distance  from  the  Engine  (over  20  feet).  It  now  becomes 
applicable  to  consider  a bus  system  with  an  on-engine  mounted 
I/O  converter  with  multiplexing  and  a MIL-STD-1553  or  equivalent 
type  bus.  This  approach  is  not  attractive,  as  the  on-engine 
mounted  electronics  to  provide  the  1/0-mux  requires  the  same 
consideration  as  the  controller  on-engine.  The  added  complexity  of 
designing  two  boxes  for  the  controller  is  a decided  disadvantage. 

This  approach  is  attractive  only  when  the  1/0-mux  is  placed 
relatively  close  to  the  engine  and  a central  total  avionics 
processor  system  is  used.  This  approach  presents  problems  with 
engine  acceptance  testing,  unless  a separate  backup  controller 

is  provided  with  each  engine. 

6. 3. 1.2  Power  Requirements 

The  power  source  for  the  IPCS  Program  was  the  conventional  MIL-STD-704  3ft  400  Hz/28V  dc 
power  available  on  the  F-lll.  However,  the  IPCS  electronics  design  was  complicated  by 
the  need  to  accommodate  the  power  bus  transients  caused  by  bus  transfers  and  load 
switching.  This  complication  would  be  eliminated  by  a dedicated  alternator,  assuming 
that  ground  power  is  provided  for  initial  start-up.  The  initial  start-up  power 
transient  would  be  masked  by  a controller  start-up  timer. 

A conventional  alternator  where  the  output  voltage  is  related  to  rotor  shaft  speed  is 
considered  the  best  choice  by  Honeywell  based  on  a study  of  four  alternator  design 
concepts.  The  output  voltage  from  the  3-phase  alternator  will  vary  from  28V  dc  to 
400V  dc  after  full  wave  rectification.  The  alternator  is  designed  to  operate  at  460° 
and  can  supply  a maximum  load  of  300W.  The  maximum  shaft  speed  is  36K  RPM  and 
ten  percent  shaft  speed  will  supply  a minimum  of  28V  dc  output  from  the  full  wave 
rectifier.  Alternators  for  this  type  application  would  be  mounted  inside  the  engine 
accessory  gear  box.  The  rotor  material  would  be  Alnico. 

The  28V  dc  to  480V  dc  output  of  the  full-wave-rectif ier  assembly  will  be  converted  to 
28  + 6 V dc  by  a switching  regulator.  This  28 V dc  supply  would  provide  approximately 
150W  capability  to  drive  solenoids,  etc.,  and  150W  to  the  electronic  controller. 

A pulse  width  modulated  inverter  would  supply  the  estimated  100  watts  required  by  the 
electronic  controller.  The  efficiency  of  this  supply  will  be  greater  than  65  percent. 

6. 3. 1.3  Back-up  System,  Fail  Safe,  Fail  Operational,  Redundancy 

The  discussion  of  reliability  in  section  3.5.6  covers  the  various  design  and  quality 
features  that  can  be  used  to  enhance  the  reliability  of  the  controller.  In  addition, 
the  discussions  of  on  vs  off  engine  mounting  imply  that  the  electronics  environment 
must  be  controlled  to  be  equivalent  to  or  better  than  the  standard  electronics 
avionics  environment  (-65°F  to  +160°F;  5G,  500  cycle  vibration)  in  order  to  ensure 
reliability.  Assuming  that  these  design,  quality,  and  environment  requirements  are 
fulfilled;  a reliability  MTBF  greater  than  30,000  hours  is  obtainable  by  use  of 
crossfed  redundancy  and  a backup  system. 


. 
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The  term  crossfeed  refers  to  switching  subassemblies  of  redundant  channels  between  the 
channels  to  bypass  a faulty  subassembly.  When  a channel-one  sensor  fails,  for  example, 
the  channel-two  redundant  sensor  is  switched  to  supply  inputs  to  both  channels. 

Failed  subassemblies  are  identified  through  an  automatic  built-in-test  (BIT),  and  the 
switching  is  performed  by  solid-state  devices.  This  crossfeed-redundancy  can  provide 
a fail -operational/fail  safe  system.  Crossfeed  redundancy  has  been  used  by  Honeywell 
in  a number  of  flight  control  systems  and  the  Space  Shuttle  Main  engine  controller. 

The  addition  of  other  IPCS  features  such  as  automatic  reversion  to  a simple  hydro- 
mechanical backup.  Manual  selection  of  the  same  backup  would  provide  an  additional 
fail -operational  (reduced  capability)  system.  In  addition,  a manual  engine  shut-down 
capability  will  provide  for  fail  safe  operation  of  multi-engine  aircraft. 

6. 3. 1.4  Mechanical  Design 

The  engine  design  should  if  feasible,  provide  for  shock  mounting  and  insulation 
of  the  electronics  controller.  An  air-cycle  heat  exchanger  could  then  be  used  to 
cool  the  controller.  The  controller  should  be  designed  such  that  its  internal  power 
dissipation  will  be  less  than  100W  as  a design  goal. 

If  these  conditions  can  be  satisfied,  the  electronics  packaging  can  consist  of  standard 
packaging  concepts  with  electronic  circuitry  designed  such  that  internal  power 
dissipation  with  a maximum  ambient  of  160°F  will  never  exceed  a 125°C  junction  temperature. 

6. 3. 1.5  Testability,  Maintainability,  Dispatchability 

The  DPCU  utilized  in  IPCS  provided  good  testability,  maintainability,  and  dispatchability 
for  a research  system.  A production  system  will  require  a design  which  provides  automatic 
integral  preflight,  a semi-automatic  flight  line  tester,  and  a Least  Replaceable  Unit 
(LRU)  repair  station.  The  mechanical  design  must  consider  ease  of  replacement  of  LRU's 
to  improve  maintainability.  In  addition,  the  inclusion  of  dual  redundant  crossfed 
channels  or  other  backup  would  improve  dispatchability. 

6. 3. 1.6  Interface  to  Other  Systems 

The  principal  IPCS  Interfaces  were  those  between  the  controller  and  the  engine  (sensors 
and  actuators);  the  manual  inlet  control;  the  NASA  recording  system;  and  the  aircraft 
installation.  These  interfaces  have  great  potential  for  problems,  therefore,  coordination 
and  design  review  meetings  at  the  working  engineer  level  must  be  held  at  regular 
intervals  to  review  these  interfaces.  Such  meetings  held  during  the  IPCS  program 
were  more  effictive  than  the  use  of  interface  specifications  alone  would  have  been. 

Another  technique  used  was  the  loan  of  actual  sensors  and  actuators  to  the  control 
designer  during  the  circuit  breadboarding  stages.  This  facilitated  checkout  of  the 
interface  long  before  the  integration  of  the  system,  and  many  potential  problems  were 
avoided. 

The  design  of  the  I/O  for  the  IPCS  controller  considered  failure  modes  of  interfacing 
equipment.  Current  limiting  and  voltage  clamping  were  used  to  protect  the  DPCU. 

It  is  recommended  that  like  precautions  be  taken  on  future  engine  controller  designs. 

Perhaps  the  best  indicator  of  synergy  in  the  IPCS  program  was  the  ability  of  Boeing, 

P&WA,  Honeywell,  NASA/Lewis,  and  NASA/DFRC  personnel  to  work  together  in  the  solution 
of  interface  problems.  An  early  definition  of  the  I/O  was  established  within  a month 
of  go-ahead.  Constant  review  and  update  of  these  I/O  tables  and  specifications  by 
all  parties  established  good  working  relationships.  Movement  of  the  controller  to 
the  field  test  arenas  of  Hartford,  Connecticut;  Cleveland,  Ohio;  and  Edwards, 

California,  was  marked  by  a high  degree  of  cooperation  and  "espirit  de  corps". 
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The  following  recommendations  are  provided  based  on  IPCS  experience; 


1.  Provide  early  preliminary  I/O  tables  and  specifications  which 

are  reviewed  and  updated  throughout  the  early  stages  of  the  program. 

2.  Hold  working  coordination  meetings  to  brainstorm,  and  to  define 
interfaces. 

3.  Provide  actual  interface  hardware  to  the  control  designer  during 
the  breadboard  stages  of  development. 

4.  Specify  clamping  and  current  limiting  requirements  at  the 
interfaces.  Specify  other  design  requirements  to  protect  the 
controller  in  the  event  of  an  external  failure. 

5.  Establish  and  demand  "espirit  de  corps"  between  participants 

in  the  program.  Insist:  You  must  work  together! 


6. 3. 1.7  Computer  Configuration 


■ 


I 


1 


The  chronological  development  of  control  systems  has  in  the  past  usually  started  out 
with  the  selection  of  the  computer.  The  system  has  then  been  configured  around  that 
computer.  The  IPCS  computer  was  selected  that  way,  and  the  flexibility  of  this 
computer  insured  that  a system  for  a research  program  could  be  configured. 

Design  trade  studies  using  state-of-the-art  microprocessors  in  various  configurations 
must  be  performed.  The  specifications  must  not  prevent  the  computer  systems  designer 
from  configuring  the  optimum  computer  for  the  system.  It  is  recommended  that  a trade 
study  between  a single  processor  and  a multi -processor  be  performed. 

The  multi -processor  system,  if  selected,  could  use  a micro-processor  for  control  of  the 
I/O.  This  micro-processor  would  provide  control  of  the  analog-digital  converters,  etc.; 
it  would  convert  raw  data  to  corrected  data,  and  would  perform  other  data  handling 
calculations.  The  results  of  its  work  would  be  periodically  placed  in  I/O  scratch-pad 
memory  which  would  be  accessed  by  the  algorithm  solution  processor(s).  This  I/O 
processor  approach  is  further  described  in  section  6.3.1.10,  I/O  Design.  A second 
processor  (and  possibly  a third)  would  be  used  for  performing  the  basic  algorithm 
solutions.  The  anticipated  advantages  of  a multi-processor  system  are  adequate 
capacity  with  the  use  of  si  owe1'  and  less  expensive  processors,  better  power 
distribution  fewer  potential  EMI  problems,  and  easier  programming. 

A single-processor  system  if  selected,  could  be  very  similar  to  the  HDC-601  used  on 
IPCS,  although  with  the  deletion  of  some  features.  It  would  probably  be  one  of  the 
new  militarized  state-of-the-art  micro-processors . 

6. 3. 1.8  Memory  Configuration 

The  lowering  cost  of  solid-state  memory  devices  indicate  that  they  will  ultimately 
replace  core  and  plated  wire  memories.  These  memories  not  only  promise  lower  cost, 
but  also  provide  smaller  size  and  ease  of  interfacing.  In  the  early  development 
of  the  controller,  volatile  Random  Access  Memory  (RAM)  can  be  used  in  conjunction 
with  a cassette  for  permanent  storage  of  the  pregram.  At  each  power  up  the  RAM 
would  be  externally  loaded  from  the  cassette.  When  the  controller  program  has  been 
perfected,  the  fixed  program  locations  can  be  placed  in  Read-Only  Memory  (ROM),  while 
the  variable  locations  will  continue  as  RAM.  Device  constants  such  as  those 
associated  with  specific  pressure  transducers  or  engine  trimming  can  be  saved  in 
Programmable  Read-Only  Memory  (PROMS).  A small  ROM  can  be  installed  as  an  integral 
part  of  each  pressure  transducer,  so  that  changing  a transducer  will  automatically 
change  the  constants  associated  with  the  unit. 

The  configuration  and  control  of  the  controller  memory  depends  upon  the  computer 
configuration  selected  as  a result  of  the  computer  tradeoff  study.  Another  effect 
on  memory  configuration  and  control  Is  its  dependency  on  the  redundancy  configuration 
selected  for  the  controller. 

The  recommendations  for  memory  configuration  are: 
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1.  Use  solid-state  memories 

2.  Use  all  RAM's  loaded  by  cassettes  during  initial  development 

3.  Use  integral  ROMS  for  devices  with  specific  constants 

4.  Convert  the  final  fixed  program  into  ROMS 

5.  Provide  some  RAM  for  scratch-pad  memory  requirements 

6.  Final  memory  configuration  is  dependent  upon  computer  and 
reliability-redundancy  tradeoff  studies 

6. 3. 1.9  Transducer  and  Actuator  Interface  Requirements 

A number  of  the  sensors  and  actuators  used  on  I PCS  required  an  inordinate  amount  of  electronics 
in  the  I/O  interface.  Figures  6.3-1,  -2,  -3,  provide  trade  comparisons  of  various  IPCS  electronic 
I/O  conversions.  These  may  be  used  in  studies  for  the  design  of  an  I/O  that  consists  of  A/D 
converters,  D/A  converters,  S&H  circuitry,  analog  MUX  circuitry,  demod  circuitry,  and  torque 
motor  drivers.  The  recommended  I/O  is  described  in  Section  6.3.1.10  "I/O  Design".  These 
recommendations  reflect  the  electronic  circuit  design  optimization  only. 

Figure  6.3-1  compares  the  amount  of  hardware,  accuracies,  conversion  times,  and  other  features 
of  strain-gage  vs.  quartz  crystal  pressure  transducers.  These  comparisons  are  primarily  concerned 
with  the  electronics  required  for  conversion  of  the  two  signal  types.  IPCS  has  demonstrated 
that  stable  A/D  converters  with  accuracy  less  than  +0.1%  are  obtainable.  It  has  also  been 
shown  that  frequency-signal  pressure  transducers  can  be  converted  with  an  accuracy  better  than 
0.06%.  Correction  and  calibration  constants  were  applied  by  the  computer  for  both  conversion 
methods.  The  new  state-of-the-art  solid-state  strain-gage  bridge  pressure  transducers  promise 
accuracy  comparable  to  the  quartz  crystal  transducers. 

IPCS  experience  indicates  that  a pressure  transducer  which  provides  a DC  voltage  signal  is 
preferred  over  a frequency  signal  transducer  if  either  is  capable  of  providing  the  desired 
accuracy.  Less  time  and  hardware  required  for  the  conversion  make  the  DC  signal  desirable. 

The  IPCS  MUX-A/D  conversion  required  205  microseconds,  while  Frequency-to-Digital  (F/D) 
conversion  required  10  to  15  milliseconds. 

IPCS  demonstrated  that  position  measurements  can  be  made  either  by  resolvers  or  by  LVDTs. 

Another  possibility  is  a Rotational  Variable  Differential  Transformer  (RVDT),  which  has 
conversion  and  excitation  requirements  similar  to  the  LVDT.  Figures  6.3-2  provides  a comparison 
of  these  position  sensors.  If  an  A/D  converter  is  present,  the  LVDT  or  RVDT  position  sensor  is 
desirable  as  the  amount  of  hardware  required  is  less  than  that  required  for  a Resolver-to- 
Digital  (R/D)  converter.  The  time  to  convert  with  a R/D  converter  is  1 MS  (for  a 1 KHz  excitation) 
while  the  IPCS  A/D  converter  performed  the  conversion  in  205  microseconds.  Less  hardware  and 
time  to  convert  are  features  that  make  the  LVDT  and  RVDT  the  attractive  position  sensors. 

The  resolver  conversion  can  also  be  performed  by  demodulation,  A/D  conversion,  and  then  a ratio 
calculation  by  the  computer.  This  method  requires  precision  excitation  or  a measurement  of  the 
excitation  for  correction  by  the  computer. 

The  impact  of  output  actuators  on  the  electronics  design  is  shown  in  Figure  6.3-3.  This  chart 
shows  that  the  IPCS  stepping  motor  outputs  required  more  hardware  and  more  power  than  the 
torque  motor  outputs.  The  D/A  - S&H  outputs  were  also  used  for  other  uses  such  as  data  acquisition 
or  indicator  drivers.  The  D/A  usage  can  he  tasily  expanded  by  the  addition  of  output  mux,  SSH, 
and  current  source  torque  motor  driver  circuitry. 

The  lower  hardware  and  power  requirements  and  the  greater  flexibility  of  torque  motor  interface 
electronics  over  stepping  motor  interface  electronics  indicates  that  torque  motors  are  attractive 
for  position  outputs. 
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Figure  6.3-1  Electronic  Signal  Processing  of  Pressure  Transducers 
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Figure  6.3-2  Electronic  Signal  Processing  for  Position  Transducers 
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Figure  6.3-3  Electronic  Conversion  for  Position  Outputs 
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Figure  6.3-4  Recommended  Input  Electronics  Configuration 


6.3.1.10  Input/Output  (I/O)  Design 


The  I/O  electronics  hardware  desiqn  requirements  are  a function  of  the  transducer  and  actuator 
devices  to  be  interfaced.  The  previous  paragraph  discussed  IPCS  experience  in  designing  the 
interface  unit  (IFU)  and  the  impact  of  transducer  and  actuator  selection.  The  conclusions 
reflect  the  electronic  circuit  design  optimization  only;  other  considerations  such  as  accuracy 
requirements  may  affect  the  I/O  design. 

Figure  6.3-4  shows  a recommended  input  electronics  configuration  based  on  Table  3.1-1.  All 
input  interfaces  are  classified  under  three  basic  types;  (1)  high  level  (HI)  DC  or  signals 
that  can  easily  be  converted  to  DC,  (2)  discretes,  (3)  serial  digital  data.  The  pressure 
transducers  are  shown  as  an  integral  part  of  the  input  electronics.  The  IPCS  system  design 
features  of  dual  A/D  converters  with  auto-null  and  built-in  self  test  features.  DC  excitation 
generators,  AC  excitation  generators,  buffer  amplifiers  and  discrete  interfaces  similar  to 
those  used  on  IPCS  are  recommended  also.  New  features  not  covered  by  IPCS  experience,  do  exist, 
however.  An  autonomus  I/O  is  one  of  the  most  attractive  of  these. 

The  Autonomous  I/O  refers  to  an  I/O  which  is  independent,  self-contained  and  self  governing. 

It  would  have  a scratch  patch  memory  (SPM)  that  becomes  an  extension  of  the  CPU  memory  ard 
requires  only  to  be  read  to  obtain  the  latest  data,  which  will  never  be  more  than  2.56  milli- 
seconds old.  The  programmer  does  not  have  to  be  concerned  with  I/O  Programming  requirements 
regarding  timing.  Since  programming  cannot  effect  I/O  timing.  His  task  is  only  related  with 
the  propulsion  system  control  algorithm.  The  load  on  the  central  computer  is  significantly 
reduced,  because  instructions  are  not  required  for  the  I/O  control.  A micro-processor  can 
perform  data  conversion  and  validity  testing.  It  can  also  perform  built-in-test  and  limited 
backup  control . 

An  autonomous  I/O  makes  it  easy  to  implement  an  I/O  interface  to  a serial  bus  (such  as  the  MIL- 
STD-1553  bus)  because  only  a remote  scratch  pad  memory  (SPD)  must  be  interfaced.  The  SPM  acts 
as  an  external  interrupt  buffer.  The  serial  bus  also  provides  inherent  capability  for  cross- 
feeding at  the  I/O  to  CPU  interface  for  redundant  system  reliability  optimization. 

The  autonomous  I/O  will  require  the  same  basic  hardware  now  used  in  IPCS  for  the  computer 
interface.  The  implementation  of  a recommended  full  autonomous  I/O  is  shown  by  Figure  6.3-5 
Timing  Control  of  Input  Electronics,  Figure  6.3-6  Input/Output  Electronics  128  Word  Address 
Counter  and  Figure  6.3-7  SPM-Timing  Sequence  (Partial).  The  Address  Counter  generates  a hardware 
controlled  2.56  milli-second  cycle  of  128  word  addresses.  The  timing  is  established  so  that 
the  CPU  never  has  to  wait  longer  than  2 microseconds  for  data  from  the  SPM. 

It  is  possible  to  expand  the  number  of  A/D  inputs  from  the  32  shown  on  Figure  6.3-5  to  64  as 
state-of-the-art  techniques  can  reduce  by  half  the  time  alloted  per  A/D  conversion.  It  should 
also  be  noted  that  the  DISIN  can  be  increased  to  8 words  if  the  F/D  conversions  are  accomplished 
by  frequency-to-voltage  converters.  The  total  DISIN  discretes  can  then  be  8 x 16  or  128.  This 
inherent  flexibility  in  the  I/O  design  as  shown  in  Figure  6.3-5  is  a decided  advantage. 

The  Output  Electronics  portion  of  the  recommended  I/O  is  shown  in  Figure  6.3-8.  The  IPCS 
output  electronics  DA  - S&H  circuitry  used  was  autonomous.  This  feature  was  added  so  that 
software  was  not  required  to  update  the  S&H  outputs  to  prevent  droop.  The  IPCS  IFU,  therefore, 
had  an  integral  autonomous  I/O  feature.  It  is  recommended  that  this  autonomous  feature  be 
expanded  in  the  output  electronics  to  include  the  servicing  of  discrete  output  buffers  and 
parallel  to  serial  digital  outputs. 


6.3.1.11  Software 


The  use  of  a microprocessor  in  an  autonomous  I/O  as  a distributed  parallel  processing  multi- 
processor system  will  require  development  of  separate  software  for  each  processor.  If  the 
interaction  between  processors  can  be  limited  to  time  enabled  control  of  access  to  a common 
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6.3.1.12  Cabling 


The  selection  of  double  shielded  cable  and  differential  mode  coupling  for  low  level  signals  was 
effective  for  IPCS.  It  did,  however,  generate  considerable  cable  weight.  The  shorter  cables 
related  to  an  on-engine  mounting  of  the  electronic  controller  are  one  solution  to  the  cable 
weight  problem.  A second  solution  could  be  the  conversion  and  serialization  of  data. 

Further  system  Improvements  may  be  obtained  by  the  use  of  fiber  optics.  The  fiber  optics 
coupling  promises  reduced  emi/rfi  susceptability  as  well  as  reduced  weight.  The  high  temperature 
(450-700°C)  capability,  total  electrical  Isolation,  no  spark/fire  hazard,  no  short  circuit 
loading,  no  ringing/echo  features  of  the  fiber  optic  cable,  are  advantages  that  force  its 
consideration.  A trade  study  must  be  performed  to  select  a system  that  optimizes  the  cable 
design  and  takes  advantage  of  state-of-the-art  technology. 

6.3.2  Controller  Design,  Fabrication  and  Test 

A system  breaaooard  should  be  fabricated,  tested  and  Interfaced  with  a hybrid  simulation  of 
the  engine.  Parts  selection  should  follow  the  expeditious  plan  of  order-of-preference  selection 
with  the  possibility  of  approved  non-standard  parts  as  a last  resort. 

The  detailed  design  requirements  definition  should  be  documented  in  two-part  Design  Specifications 
DS)  for  both  hardware  and  software.  The  hardware  specifications  provide  system  definition  and 
performance  requirements.  The  software  specifications  will  provide  control  algorithms  to  be 
Implemented  and  methodology  for  their  implementation.  The  Part  II  of  these  design  specifications 
should  be  developed  concurrently  with  the  design  to  provide  documents  which  define  the  testing 
required  to  prove  compliance  to  the  Part  I design  requirements. 

6.4  FLIGHT  ASSURANCE  TESTING 

Flight  assurance  testing  (FAT)  is  conducted  on  prototype  hardware  to  provide  confidence  that 
the  hardware  will  survive  in  the  flight  environment  long  enough  to  fulfill  the  flight  test 
objectives.  In  general,  the  test  articles  must  subsequently  be  flown;  therefore,  the  tests 
must  be  designed  and  conducted  judiciously  to  avoid  expending  an  excessive  portion  of  the 
articles  lifetime  in  the  test  process.  This  is  especially  true  of  the  vibration  tests.  It  may 
for  example  be  possible  to  use  mass  simulators  instead  of  electronic  components  during  vibration 
tests  to  develop  shock  mounts,  etc.  It  may  be  determined  that  the  standard  military  specifications, 
e.g.,  MIL-E-5400,  call  out  testing  to  environmental  conditions  that  are  far  more  severe  than 
the  component  will  encounter  in  operation.  In  this  case  It  may  be  advisable  to  seek  a deviation 
from  the  specified  test.  If,  however,  the  full  Mil-Spec  test  must  be  conducted  and  it  is 
suspected  that  an  undue  portion  of  the  life  of  a key  component  is  consumed  in  the  process,  it 
may  be  cost-effective  to  provide  additional  spares  of  the  affected  component  for  the  flight- 
test  program. 

6.4.1  Flight  Assurance  Testing  (FAT)  of  Engine  Related  Components 

The  requirements  for  Flight  Assurance  Testing  (FAT)  of  engine  related  components  must  of 
necessity  address  the  interrelationship  between  the  government  specifications  or  other  involved 
contractor  specifications  and  the  basic  elements  of  flight  assurance.  The  requirements  for 
these  specifications  are  usually  a negotiated  part  of  the  program  contract.  The  specifications 
are  the  formalized  spectrum  of  experience  that  governs  the  program  test  philosophy.  A list  of 
applicable  specifications  is  negotiated  during  the  formal  drafting  of  the  program  contract. 

Careful  attention  should  be  given  to  the  level  to  which  these  specifications  apply,  since 
specifications  can  have  a major  Impact  on  program  schedule  and  cost.  The  outcome  of  these 
negotiations  will  set  the  tone  for  all  future  testing.  Decisions  incorrectly  made  at  this  time 
are  not  irrevocable,  but  certainly  could  Impose  undue  burden  on  all  parties. 
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The  system's  suitability  for  flight  must  be  established  prior  to  performing  the  actual 
flight  test  portion  of  the  program.  Three  methods  to  establish  the  necessary  level  of 
assurance  are: 

1.  Flight  Assurance  by  similiarity- 

The  selection  of  hardware  that  has  a documented  history  of  successful 
use  on  prior  flight  test  programs. 

2.  Flight  assurance  by  analysis- 

The  use  of  design  analysis  techniques  to  provide  the  necessary 
indications  that  program  hardware  have  adequate  safety  margins. 

3.  Flight  assurancy  by  test- 

The  use  of  tests  carefully  planned  to  probe  the  areas  of  the  design 
which  have  the  least  documented  history,  or  the  use  of  system  tests 
run  to  establish  the  viability  of  the  overall  program. 

Note  that  the  use  of  one  avenue  does  not  necessarily  exclude  the  use  of  another. 

These  are  complementary  functions  and  judgment  must  be  used  in  their  application, 
because  of  their  potentially  large  Impact  on  program  cost  and  program  schedule.  rMs 
judgment  must  be  tempered  by  the  applicability  of  the  previously  established  contract 
specifications.  Obviously,  the  minimum  risk  program  position,  and  consequently  minimum 
cost  and  minimum  schedule  position,  is  assumed  if  all  the  program  hardware  is  similar 
to  hardware  which  has  a documented  history  of  successful  prior  use.  Hence,  a 

program  goal  must  be  to  maximuze  the  use  of  hardware  with  successful  prior  use.  Since 

by  its  very  nature  the  development  program  is  concerned  with  proving  an  untried 
principle,  through  test,  some  untried  hardware  would  be  expected.  A two-fold  approach 
is  required  to  assure  that  this  hardware  is  suitable  for  flight. 

First,  it  must  be  adequately  shown  by  analysis  that  adequate  safety  margins  exist  In 

critical  areas  of  the  design.  The  "Critical  Areas"  are  of  necessity  a judgment  on 

the  part  of  the  design  system,  which  encompasses  the  designer,  the  stress  analyst, 
the  metallurgist,  and  the  project  engineer.  At  this  point  in  time  a design  is  still 
on  paper;  therefore,  changes  can  be  easily  effected  with  minimum  program  Impact. 

Second,  the  required  individual  hardware  test  sequences  must  be  established  during 
this  preliminary  design  phase.  Individual  hardware  test  sequences  are  established  by 
a combination  of  the  judgment  of  the  personnel  associated  with  the  design  of  the  part, 
their  knowledge  of  the  system  that  will  contain  the  part,  and  the  specification 
associated  with  the  program  contract. 

6.4.2  Flight  Assurance  Testing  of  Electronic  Equipment 

Flight  Assurance  Testing^Jrom  the  electronic  manufacturers  standpoint  will  vary 
depending  his  degree  of  responsibility  In  the  program  and  the  stage  of  the  program. 

In  an  ideal  program  such  as  IPCS,  where  the  control  manufacturer  is  an  Integral  part 
of  the  team  and  has  participated  from  the  outset,  he  may  not  have  specified  the 
control  mode,  but  he  will  have  been  plainly  involved  In  Its  implementation  and 
modification.  As  such,  he  will  have  a real  time  simulation  of  the  propulsion  plant 
and  the  initial  development  FAT  will  be  of  two  types: 

1.  System  hardware  integration  tests  where  the  fundamental 
operation  of  the  hardware  and  its  software  will  be  tested 

with  a real  time  simulation  of  the  plant  to  ensure  compatibility. 

2.  Hardware  tests  conducted  with  abreviated  program  of 
environmental  testing  simulating  flight  conditions  to 
demonstrate  that  the  hardware  is  suitable  for  Initial 
development  type  flight  tests. 

It  is  Important  for  the  planner  to  recognize  the  need  for  the  controls  manufacturer  to: 

1)  have  the  appropriate  test  requirements  from  the  engine  and  airframe  manufacturers. 

2)  have  a tailored  real  time  simulation  of  the  engine;;  3)  to  Incorporate  time  in  the 
program  schedule  for  the  various  FAT;  4)  have  the  test  procedure  documentation 
preparation  and  approval  cycles  planned;  5)  have  appropriate  peripheral  equipment  to 
test  the  hardware;  6)  have  planned  the  hardware  and  software  development  programs  to 
ensure  synchronization  and  finally,  since  the  program  Inevitably  entails  change  to 
the  initial  hardware,  extra  hardware  and  peripherals  should  be  provided  so  that  the 
controls  vendor  can  verify  the  changes  that  are  made. 
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FAT  of  the  hardware  include  the  following  type  testing:  1)  functional  of  both  a short 

(abbreviated)  form  and  long  (complete)  form  to  establish  pre  and  post  test  condition 
of  the  equipment;  2)  high  and  low  temperature  conditions;  3)  altitude  conditions;  4) 
vibration;  5)  shock,  etc.  Initial  tests  are  generally  non  destructive,  intended  only 
to  ensure  that  the  equipment  is  flightworthy,  as  opposed  to  qualification  tests  which 
establish  life/durabllity  and  associated  performance. 

Engine  mounted  equipment  which  is  subject  to  environmental  extreme  in  its  life  should 
also  be  required  to  demonstrate  fatigue  resistance  from  long  term  thermal  cycling 
between  thermal  extremes.  It  is  important  to  recognize  this  requirement  in  the 
planning  stage  because  it  has  a profound  effect  upon  the  design  itself  as  well  as 
the  test  program. 

6.4.3  Flight  Assurance  Testing  of  Airframe  - Mounted  Equipment 

The  I PCS  program  did  not  generate  any  unusual  requirements  in  the  FAT  of  airframe 
mounted  equipment.  The  vibration  tests  had  by  far  the  most  significance  for  items 
such  as  the  shock  probe,  the  LVDTs  used  for  sensing  inlet  surface  positions,  and  the 
DPCU  box. 

The  shock  probe  and  LVOTs  were  vibrated  to  ±15g  over  the  frequency  range  from  90  to 
2000  hz  per  NASA  DFRC  Process  Specification  No.  21-2,  The  test  articles  were  marked 
"For  Ground  Use  Only"  subsequent  to  the  tests  and  so  were  not  flown. 

The  DPCU  box,  which  contained  the  DCU,  the  IFU,  and  the  PSU,  was  vibrated  only  to 
±5g  since  it  was  to  be  mounted  in  the  weapons  bay  and  so  was  subjected  to  lower 
vibration  levels  than  equipment  mounted  In  the  inlet  area.  The  vibration  input  Is 
shown  by  Figure  6.4-1.  Wooden  blocks  ballasted  to  simulate  the  weight  and  c.g. 
location  of  the  electronic  components  were  installed  during  these  tests  instead  of 
those  components. 

No  shock  isolation  was  used  In  the  original  configuration  and  vibration  loads  as 
high  as  ±21g  were  measured  at  some  box  locations  with  a ±5g  input  at  the  mounting 
pads.  This  was  clearly  unacceptable  since  the  electronic  modules  were  also  designed 
to  tolerate  ±5g. 

The  tests  on  the  DPCU  box  were  re-run  with  standard-sized  pads  of  synthetic  rubber 
used  for  shock  Isolation.  The  properties  of  the  material,  BMS  1-50  Duro  60  rubber 
and  BMS  1-11  Duro  60  rubber  were  known.  It  was  possible,  with  some  experimentation 
with  pad  thickness  and  configuration,  to  reduce  with  frequency  and  amplitude  of  box 
resonance  to  acceptable  levels.  The  spring  constants  and  damping  coefficients  of 
the  rubber  mounts  as  calculated  from  the  known  configuration  and  the  properties  of 
the  rubber  were  used  to  select  shock  mounts  of  standard  design. 

Tests  run  using  the  production  shock  mounts,  Barry  Model  T64-AB-35  on  the  forward 
end  of  the  box  assembly  and  Model  T64-AB-80  on  the  aft  end,  verified  the  mount 
selection.  Subsequent  tests  run  with  the  electronic  components  installed  instead 
of  the  mass  simulators  were  conducted  without  incident. 

The  following  aspects  of  the  experience  related  above  are  considered  relevant  to  IPCS 
methodology: 

1.  It  is  extremely  difficult  to  design  structures  that  will  not 
amplify  input  vibrational  loads  at  some  frequency.  If  a module 
must  tolerate  a specified  vibration  level  at  the  mounts,  then 
almost  certainly  some  form  of  isolation  must  be  provided  or  some 
of  the  components  must  be  able  to  tolerate  much  higher  levels. 

2.  The  use  of  mass  simulators  spared  the  electronic  component  from 
the  abuse  they  would  otherwise  have  suffered  during  the  preliminary 
and  developmental  tests  of  the  mounting  system. 

3.  The  spring  constants  and  damping  coefficients  required  for  satisfactory 
vibration  Isolation  can  be  determined  experimentally  by  using  material 
of  known  dimensions  and  properties.  It  Is  not  suggested  that  this 
approach  replace  analysis,  but  it  can  supplement  and  verify  analysis 

and  is  certainly  a viable  approach  when  a solution  must  be  found  quickly. 
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Figure  6.4-1  Vibration  Input  to  DPCU  Box 


4.  Mass  simulators  cannot  represent  precisely  the  compliance  and 
damping  characteristics  of  other  hardware  components;  therefore, 
it  Is  important  to  conduct  final  verification  testing  with  the 
flight  configuration. 

The  shock  tests  that  had  been  specified  for  the  DPCU  (15g  half-sine  pulse  of  11  msec 
duration)  were  deleted  from  the  test  plan  with  government  approval  when  it  was 
learned  that  the  test  would  entail  nothing  more  than  dropping  the  unit  a fraction  of 
an  inch  onto  a calibrated  rubber  pad.  It  is  not  clear  that  such  a test  is  useful, 
considering  that  the  components  are  subjected  to  harder  usage  during  normal  handling. 

6.5  SHOCK  MOUNTING  OF  EQUIPMENT 

IPCS  experience  indicates  that  shock  isolation  of  sensitive  equipment  Is  cost 
effective  and  should  be  done  In  virtually  every  case  in  which  it  Is  feasible.  Shock 
mounting  for  vibration  considerations  should  be  assessed  early  in  the  development 
phase  of  a program. 

Experience  with  the  DPCU  shock  mounts  was  discussed  in  paragraph  6.4.3  above.  Another 
method  of  shock  Isolation  that  was  used  very  successfully  was  simply  to  wrap  a blanket 
of  synthetic  foam  material  around  the  sensitive  component.  This  was  done  to  the 
Paroscientific  pressure  transducers,  which  have  a quartz-crystal  sensing  element 
that  is  easily  shattered.  Three  things  were  accomplished  simultaneously;  the  units 
were  protected  against  shocks  and  vibration  transmitted  through  the  structure,  they 
were  protected  against  rough  handling  (a  tap  with  a wrench  can  apply  several  hundred 
g's  to  a small  hard  object),  and  they  were  protected  against  high  temperatures. 

If  pressure  lines  are  to  be  plumbed  Into  shock-isolated  components,  flexible  line 
segments  should  be  considered,  both  to  avoid  transmitting  shock  and/or  vibration 
through  the  plumbing  and  to  inhibit  fatigue  failures  of  the  plumbing  itself. 

6.6  SPARES  PHILOSOPHY 

In  principle  the  cost  of  operating  a development  program  can  be  minimized  by  providing 
spare  parts  or  components  if 

CS  < P * CF 


I 


where : 

CS  = cost  of  spare 

P = probability  of  needing  the  spare 
CF  = cost  impact  of  a failure  if  no  spare  Is 
available  when  required. 

Since  P * f (MTBF),  where  MTBF  can  vary  by  several  orders  of  magnitude  for  a given  part. 
It  is  recommended  that  vendor  MTBF  estimates  be  compared  with  actual  experience  prior 
to  determining  the  number  of  spares.  Since  the  IPCS  program  used  an  F-111E  it  was 
possible  to  use  field  experience  as  provided  by  the  Air  Force  Data  System  AF -66-1  and 
the  Boeing  Experience  Analysis  Center.  If  possible,  compare  experience  on  different 
aircraft  to  get  a better  "feel"  for  the  MTBF  of  selected  components. 

In  practice  the  information  required  to  estimate  CF  and  to  exercise  the  trades  is  rarely 
available.  The  IPCS  philosophy  therefore  was  to  provide  spares  of  virtually  every 
Item  except  the  fllqht  test  aircraft:  Two  engines  were  modified,  two  complete  DPCUs 

were  fabricated,  complete  with  test  set  units,  teletypes,  etc.,  two  Inlet  control  modules 
and  two  sets  of  Inlet  position  transducers  were  provided.  In  the  case  of  pressure 
transducers,  two  engine  sets  plus  one  spare  of  each  part  number  of  the  well  developed 
MB  Allnco  units  were  procurred.  The  Paroscientific  transducers  were  not  considered 
mature,  proven  designs  at  the  time,  so  1-1/2  ship  sets,  or  12  units  were  purchased. 

The  fluidic  T4  transducers  were  considered  to  be  short-lived  expendible  Items,  so 
enough  units  were  provided  to  last  through  the  projected  engine  operating  time.  These 
were  not  therefore  considered  spares  in  the  accepted  sense  of  the  term. 


96 


The  IPCS  spares  philosophy  proved  to  be  completely  satisfactory.  Absolutely  no  test 
time  was  lost  due  to  unavailability  of  spare  components  or  parts  provided  as  IPCS 
hardware.  On  the  other  hand,  if  all  unused  parts  were  returned  to  the  manuracturers 
for  a full  cash  rebate,  the  sum  recovered  would  be  only  about  0.3%  of  the  cost  of 
the  program. 

The  availability  of  two  complete  sets  of  hardware  also  greatly  facilitated  the  conduct 
of  the  test  program.  With  four  major  system-level  tests,  there  were  three  Instances 
where  a set  of  hardware  was  moved  to  a test  site,  set  up  and  check-out  initiated 
before  the  previous  test  in  the  series  had  been  completed. 

In  summary,  based  on  IPCS  experience,  there  does  not  appear  to  be  any  justification 
for  procurring  and  maintaining  less  than  one  complete  set  of  spares  for  a major 
development  program.  The  decision  on  whether  to  procure  more  must  be  based  upon  the 
following  considerations: 

1.  Cost  of  additional  spares 

2.  Probability  of  requiring  additional  spares 

3.  Lead  time  required  to  procure  additional  units 

4.  Impact  to  program  if  spare  Is  not  available  when  required 

The  cost  of  additional  spares  is  usually  known  firmly  only  when  the  Initial 
procurement  is  made,  unless  the  price  of  additional  units,  to  be  procurred  later,  Is 
written  Into  the  purchase  contract.  The  probability  of  requiring  additional  spares 
may  be  estimated  from  the  expression 

Total  projected  unit  operating  time 
2 (KTBF  X No  of  spares) 

The  degree  of  conservatism  that  Is  adopted  must  be  based  upon  the  Impact  to  the 
program  if  a replacement  component  is  unavailable  for  the  projected  lead  time. 
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7.0  SYSTEM  INTEGRATION  AND  TEST 


There  are  two  ways  in  which  a complex  system  may  be  integrated  and  tested. 

One  approach  is  to  build  and  assemble  a complete  system  and  hope  that  it  works.  The 
other  possibility  is  to  organize  a step-by-step  progression  of  tests  of  increasing 
complexity,  with  each  test  building  upon  the  results  of  the  previous  test. 

The  put-it-all-together-and-try-it-approach  is  attractive  and  cost  effective  if  it  can 
be  done  Inexpensively  and  with  low  risk.  No  complex  system  has  ever  been  known  to 
work  at  first  trial,  however,  and  a high-performance  propulsion  system  requires  a 
very  costly  test  facility.  Trouble  shooting  during  facility  occupancy  is  notoriously 
expensive.  Furthermore  there  is  a finite  and  increasing  probability  that  a minor 
flaw  would  cause  destruction  of  the  test  article  and  extensive  damage  to  the  test 
facility. 

Under  the  circumstances  we  strongly  support  the  step-by-step  approach.  Our 
recommendations  relative  to  the  planning  and  execution  of  system  integration  and 
test  activities  are  given  blow. 

7.1  INTEGRATION  PHILOSOPHY  - THE  STEP-BY-STEP  APPROACH 

The  Integration  and  test  philosophy  recommended  for  propulsion  controls  on  a high- 
performance  aircraft  is  diagrammed  in  Figure  7.1-1.  The  sequence  shown  is  essentially 
that  followed  during  the  IPCS  program,  with  some  additional  steps  that  would  be 
required  if  a complex  inlet  were  used  on  the  aircraft. 

Interface  tests  would  be  initiated  by  the  controls  vendor  as  soon  as  the  hardware 
and  software  components  become  available.  Specimens  of  each  type  of  engine  and  inlet 
sensor  and  electromechanical  or  electrohydraul ic  component  should  be  supplied  by  the 
engine  and  airframe  manufacturers.  The  ability  of  the  electronics  to  excite  the 
transducers  and  condition  the  signals  must  be  demonstrated.  The  ability  of  the 
electronics  to  Interface  with  the  actuators  - drive  stepper  motors,  solenoids,  etc  - 
should  also  be  demonstrated  at  this  time. 

Final  pre-delivery  checkout  will  be  performed  on  the  actual  control  computer  with  its 
interface  unit,  using  a real-time  simulation  to  closed  the  loop  as  discussed  in 
Section  5.0. 

At  least  two  sets  of  electronic  hardware  should  be  supplied  for  the  subsystem  tests. 
The  IPCS  fuel  bench  test  procedure  is  basically  sound  and  is  adaptable  to  other 
programs.  In  addition,  a closed-loop  wind-tunnel  test  of  a fully  actuated  inlet  model 
is  reconmended , particularly  if  the  inlet  operates  in  a mixed-compression  mode.  The 
scale  of  this  model  should  be  as  large  as  required  to  reproduce  full-scale  geometry 
and  Reynolds  number  effects  with  fidelity.  A 1/6  - scale  model  is  probably  a 
reasonable  minimum  size. 

Sea-level-static  testing  of  the  demonstrator  engine  would  probably  be  initiated  using 
a bell-mouth  inlet.  The  introduction  of  a boiler-plate  version  of  a flight  inlet 
during  the  sea  level  test  program  is  desirable,  however,  particularly  if  the  inlet 
is  actuated  during  ground  or  low  speed  flight  operation. 

An  altitude  test  and  full  scale  wind  tunnel  test  of  a complete  propulsion  module  are 
shown  to  complete  the  integration  test  program.  The  decision  of  whether  to  Derform 
the  altitude  test  during  the  demonstrator  program  must  be  evaluated  on  a case  by  case 
basis.  The  full  scale  wind  tunnel  test  should  probably  be  deferred  to  the 
prototype  program. 

7.2  TEST  REQUIREMENTS 

The  key  to  establishing  the  specific  test  requirements  is  to  identify  the  test  events 
needed  to  assure  suitability  for  flight.  This  requires  a plan  that  focuses  attention 
on  the  various  components  and  subsystems  to  be  tested  to  permit  a timely  sequence  of 
events  that  build  upon  each  other.  Each  test  event  builds  up  to  the  next  test  event 
that  uses  more  of  the  system.  Thus  each  test  acts  as  a building  block  for  the  next 
test  up  to  the  point  of  certification.  Once  the  test  sequence  is  established, 
detailed  test  plans  for  each  are  written  to  establish  the  test  events,  requirements, 
schedules,  limits,  and  acceptance  criteria. 
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The  component  test  requirements  for  the  IPCS  program  were  identified  in  Flight  Assurance 
Test  Plans  that  outlined  all  of  the  inlet,  fuel  system,  and  engine  changes  and 
electronic  components  and  how  they  were  to  be  tested.  The  tests  included  individual 
component  open  loop  bench  testing,  vibration  testing,  system  closed  loop  bench  testing, 
and  full  scale  engine  testing  under  both  sea  level  and  altitude  conditions.  Each  test 
event  was  conducted  with  a test  plan  which  identified  the  test  hardware,  the  facility, 
the  test  configuration,  instrumentation,  test  procedure,  data  recording,  and  acceptance 
criteria.  The  testing  of  new  control  concepts  required  a wide  latitude  for  engineering 
judgment  to  permit  alterations  to  the  test  program  as  the  test  progressed.  For  the 
IPCS  program,  these  judgments  were  normally  made  by  committee  of  the  contractors  at  the 
test  site. 

7.2.1  Engine  and  Fuel  System  Test  Requirements 

The  general  test  requirements  of  engine  related  components  and  engine  tests  for  any 
program  are  usually  a negotiated  part  of  the  program  and  are  set  forth  in  the  specifications 
of  the  contract.  The  primary  test  requrement  in  a development  program  is  to  prove 
through  test  that  the  engine  is  suitable  for  flight.  This  requires  the  offical 
acceptance  of  the  engine  and  components.  Secondary  objectives  involve  evaluation  of 
new  concepts,  and  documentation  of  system  operation.  In  setting  the  general  requirements, 
personnel  involved  must  be  aware  of  the  following  factors: 

1.  Airplane  mission 

2.  Engine  duty  cycle 

3.  Past  experience  with  similar  engines  and  components 

4.  New  technology  concepts 

5.  Test  facilities 

6.  Manufacturing  schedules 

7.  Test  duration  and  manpower  required  to  achieve  a given  test  objective  . 

The  general  test  requirements  are  established  and  factored  into  the  overall  program 
schedule  prior  to  program  go  ahead.  After  the  program  is  started  and  during  the 
Final  Design  Phase,  specific  test  requirements  are  identified  for  each  test  event. 

The  specific  test  requirements  have  the  same  overall  objectives,  but  are  tailored  to 
the  specific  item  being  tested  and  are  issued  as  a test  plan  containing  procedures, 
limits,  and  resources. 

7.2.2  Inlet  Test  Requirements 

There  are  five  things  that  must  be  demonstrated  in  system  level  tests  of  the  inlet 
control  system  using  the  flight  hardware  and  software: 

1.  The  ability  to  sense  and  condition  control  signals  in  real  time. 

2.  The  applicability  of  the  inlet  control  laws,  including  the  use 
of  information  derived  from  the  engine  or  airframe. 

3.  Proper  response  of  the  actuation  system. 

4.  Absence  of  adverse  interactions  between  the  inlet  and  engine  or 
between  inlet  and  airframe. 

5.  Safe  backup  modes  to  tolerate  hardware  failures. 

These  requirements  are  in  addition  to  the  requirement  to  demonstrate  inlet  performance; 
recovery,  distortion,  drag,  etc. 

7. 2. 2.1  Sensing  Inlet  Control  Signals 

Inlet  control  mode  designs  are  generally  based  on  signals  obtained  from  wind  tunnel 
tests  of  small  scale  models.  (See  paragraph  3. 1.1. 2 and  3.2.2.)  It  Is  important  that 
these  be  corroborated  both  statically  and  dynamically  using  flight  hardware  and 
software.  The  following  areas  of  concern  should  be  addressed: 

1.  Model  scale  effects  and  manufacturing  tolerances  can  affect 
the  signal  characteristics.  This  is  particularly  true  of 
supersonic  flow. 
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2.  Pneumatic  line  dynamics  can  introduce  both  phase  lag  and  transient 
errors.  The  transient  errors  are  caused  by  differences  In  the 
responses  of  the  static-pressure  and  total -pressure  legs  of  Mach 
sensors.  The  differences  may  stem  from  differences  In  line 
configuration  or  from  differences  in  probe  response  between  the 
static  and  total  pressure  sides. 

3.  The  transducer  environment  - temperature,  vibration,  and  EMI  - can 
affect  the  signal  accuracy. 

4.  Signal  conditioning  hardware  and  software  should  be  demonstrated  under 
realistic  operating  conditions.  Items  such  as  counters,  timers, 

A/D  converters,  calibration  data,  signal  ranges,  and  scaling  are 
amenable  to  bench  testing.  Signal  noise  is  a potentially  trouble- 
some element  that  cannot  be  evaluated  reliably  without  the  wind 
tunnel  or  flight  testing  of  large  scale  Inlet  hardware.  (See 
section  3.4.3.12  for  the  treatment  of  signal  noise.) 

7. 2. 2. 2 System-Level  Tests  of  Inlet  Control  Laws 

Ideally  Inlet  control  laws  should  be  demonstrated  In  wind-tunnel  tests  of  large-scale 
models  under  closed-loop  control.  (No  wind  tunnel  tests  were  conducted  during  the 
IPCS  program  - this  accounts  for  our  timidity  In  modifying  the  bill -of -materials 
control  mode  for  use  with  the  advanced  engine  control  modes.)  If  a mixed -compress Ion 
inlet  is  used,  the  closed-loop  wind  tunnel  tests  should  be  made  mandatory.  If  an 
external -compression  inlet  is  used,  the  closed-loop  wind  tunnel  tests  may  be 
eliminated  if  no  unacceptable  hazards  are  associated  with  Inaccuracies  in  inlet  surface 
positions. 

The  IPCS  inlet  control  laws  as  well  as  the  modified  actuation  system  were  tested  as 
part  of  the  fuel  test  bench  operation.  (Volume  II,  Section  6.0.)  Inlet  aerodynamics 
were  simulated  on  an  analog  computer.  Pressure  transducers  were  replaced  by  voltage 
controlled  oscillators  (VCOs)  driven  by  the  analog  inlet  simulation.  Engine/inlet 
interaction  was  implemented  through  interconnections  between  the  analog  inlet 
simulation  and  the  real  time  hybrid  engine  simulation.  The  inlet  actuators  and 
their  position  feedback  transducers  were  installed  in  a test  fixture  that  simulated 
Inertial  loads  but  not  aerodynamic  loads. 

The  principal  limit  of  the  applicability  of  the  IPCS  bench  test  approach  is  that  imposed 
by  the  fidelity  and  range  of  the  engine  and  inlet  simulation.  These  should  be 
adequate  to  perform  the  following: 

1.  Exercise  all  normal  and  back-up  inlet  control  loops  over  the 
entire  flight  envelope. 

2.  Investigate  the  effects  of  all  significant  engine-inlet 
interactions 

3.  Simulate  failures  of  all  critical  components. 

7.3  TEST  TIMING 

The  integration  and  test  timing  requirements  for  any  program  are  of  major  importance 
to  the  ultimate  success  and  cost  impact  of  the  particular  program.  It  Is  to  this  end 
that  extreme  thought  and  care  should  be  exercised  in  establishing  the  base  test 
schedule  to  be  followed  and  also  to  allow  for  revisions  to  this  schedule  as  the 
testing  progresses. 

There  is,  for  each  different  program,  an  optimum  test  schedule  that  can  be  established 
at  the  outset  of  a program.  This  optimum  schedule  should  allow  for  the  following: 

1.  Sufficient  test  time  to  complete  the  goals  established  for  each 
Intended  test. 

2.  Sufficient  schedule  time  to  allow  for  analysis  of  the  test  data 
before  proceeding  to  the  next  phase  of  testing. 

3.  Flexibility  in  the  test  schedule  to  allow  for  additional  testing 
if  necessary. 
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To  expand  on  item  1,  a most  difficult  scheduling  exercise  at  the  proposal  stage  of  a 
program,  it  should  be  recognized  that  this  scheduling  requirement  must  be  an  iterative 
process  continuing  to  the  end  of  the  test  itself.  Guidelines  that  could  be  followed 
to  meet  this  goal  are  as  follows: 

1.  Realisttc  appraisal  of  the  test  time  requirements  based  on  previous 
experience. 

2.  Comprehensive  test  plan  established  as  early  in  the  program  as 
possible. 

3.  Detailed  schedule  for  each  test  outlining  the  flow  of  hardware 
and  test  goals. 

The  second  item,  sufficient  time  for  analysis  of  data  between  test,  is  self  explanatory. 
The  tendency  to  sacrifice  this  scheduled  time  to  make  up  for  delays  in  testing  or 
to  perform  additional  testing  must  be  resisted. 

The  third  point  presents  a real  problem  when  only  one  set  of  components,  engine,  etc. 
are  being  tested  because  it  is  not  possible  to  schedule  additional  testing  around  the 

open  periods  created  by  other  test  schedules.  This  still  remains,  whatever  the  level 

or  amount  of  testing,  an  optimum  schedule  criterion  that  should  be  pursued. 

The  major  constraint  to  any  test  schedule  or  its  flexibility  is  the  cost  impact  due  to 
delays,  or  additional  testing.  This  points  out  the  need  for  skilled  program  managers 
to  assess  the  test  schedule  and  apply  sound  judement  to  either  extension  or 
termination  from  the  standpoint  of  ultimate  program  success  versus  cost  impact. 

The  IPCS  program  was  involved  with  the  integration  and  test  timing  between  three 

companies  with  three  different  pieces  of  hardware.  It  also  involved  two  sets  of 
hardware  from  each  company.  Reference  the  test  schedule,  Figure  7.3-1,  as  an  example. 

The  original  proposed  test  schedule  was  not  the  most  workable  schedule,  however, 
the  iteration  process  of  the  scheduling  which  took  place  as  the  program  progressed 
resulted  in  a test  schedule  and  sequence  of  events  which  was  very  reasonable.  The 
test  plans  for  each  test  defined  the  test  requirements  and  the  acceptance  criteria 
but  also  allowed  for  flexibility  in  the  actual  test  sequence  to  obtain  the  maximum 
utilization  of  test  time.  Also  outlined  in  the  test  plan  were  the  detailed  schedule 
of  events  and  their  proposed  completion  date.  This  proved  very  useful  in  maintaining 
a test  sequence  in  line  with  the  time  requirement.  It  is  important  that  this  type 
schedule  be  broken  down  into  the  smallest  increments  of  testing  possible  to  prevent 
an  oversight  of  a test  event  and  also  to  prevent  lingering  on  one  test  to  the  point 
of  not  completing  the  overall  test  program. 

The  time  allowed  between  test  events  for  data  anlysis  in  the  IPCS  program  was  crunched 
because  of  scheduling  and  cost  considerations.  This  is  not  desirable  and  should  be 
avoided  if  possible.  (See  Section  7.4  below). 

The  flexibility  in  the  IPCS  test  schedule  was  demonstrated  during  the  sea  level  static 
engine  testing.  During  the  testing  of  engine  P-676629  the  proposed  20  hours  of  test 
time  proved  Insufficient  to  complete  the  testing  required  to  solve  the  problems  that 
were  identified  during  test.  An  extension  was  allowed  by  mutual  agreement  of  the 
contractors  which  proved  very  beneficial  in  the  ultimate  success  of  the  program  even 
though  a penalty  was  imposed  on  the  scheduling  and  cost  of  the  program. 

7.4  TEST  DATA 

A digital  control  has  the  capability  to  output  large  amounts  of  data  on  engine  and 
control  operation.  If  properly  used  the  data  can  significantly  reduce  the  time 
required  to  Identify  and  solve  development  problems.  The  task  of  processing  and 
displaying  the  large  quantity  of  data  should  not  be  underestimated. 
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In  the  IPCS  program  two  sources  of  DPCU  data  wore  used  - 11  channels  of  analog  data  and 
59  channels  of  20  sample  per  second  PCM  data.  The  analog  data  were  available  for  on-line 
display  on  a stripchart  recorder.  The  PCM  data  were  displayed  on-line  on  an  octal  display 
and  stripchart  recorders,  and  were  processed  off-line  by  various  facility  data  systems. 

The  processed  PCM  data  were  valuable  for  post  test  analysis  and  reporting,  but 
difficulties  in  setting  up  processing  at  the  test  facilities  and  turnaround  time  largely 
prevented  the  use  of  the  PCM  data  for  system  troubleshooting.  Two  conclusions  were 
apparent  from  the  IPCS  testing:  turnaround  of  24  hours  or  less  is  essential  for  any 

data  to  be  used  for  control  troubleshooting  and  a great  deal  of  time  and  effort  are 
•required  to  interface  the  DPCU  system  with  each  facility  data  system.  The  data 
acquisition  and  data  processing  system  described  in  the  following  paragraphs  is 
designed  to  achieve  24  hour  turnaround,  integrate  with  the  DPCU  only  once,  and  provide 
the  maximum  data  visibility  during  the  course  of  the  testing. 

The  proposed  system  consists  of  a data  recording  package  designed  to  be  used  in  the 
ground  and  flight  tests  together  with  a mobile  data  processing  van  which  is  moved  from 
facility  to  facility  during  the  entire  test  program.  This  approach  will  provide  rapid 
data  turnaround  through  the  use  of  a dedicated  data  processing  facility  and  eliminate 
the  requirement  for  interfacing  with  the  facility  data  processing  systems. 

The  proposed  system  is  ideally  suited  for  relatively  small  programs,  such  as  IPCS,  in 
whicn  a single  test  system  is  used  at  a number  of  facilities.  In  a large  program 
with  flight  testing  of  several  airplanes  occurring  in  parallel  with  altitude  testing 
of  engines,  the  concept  of  a mobile  data  processing  capability  may  not  be  appropriate. 

However,  the  same  need  for  rapid  data  turnaround  and  consistent  data  system  interfaces 
will  exist.  Paragraph  7.4.2  outlines  the  specific  requirements  which  should  be  met  to 
take  advantage  of  the  capability  of  a digital  controller. 

7.4.1  Instrumentation 

During  the  study  phase  prior  to  the  demonstrator  engine  program  any  testing  performed 
will  have  to  rely  on  the  normal  instrumentation  systems  available  at  the  test  facility. 

However,  for  those  tests  beginning  with  the  demonstrator  program  bench  test  the 
control  instrumentation  will  provide  adequate  data  for  analysis  of  control  and  engine 
operation.  The  use  of  control  sensors  as  the  primary  source  of  test  data  offers  the 
following  advantages: 

1.  Consistent  instrumentation  for  all  the  testing  is  assurea. 

2.  Development  of  instrumentation  data  processing  system  is  required  only 
once  for  the  entire  program,  and 

3.  it  will  produce  the  relevant  data  for  control  system  trouble- 
shooting and  schedule  development. 

Additional  instrumentation  will  be  required  to  monitor  facility  or  airplane  operation 
and  to  measure  inlet  distortion  during  distortion  testing.  These  measurements  can 
generally  be  made  using  existing  facility  instrumentation  systems. 

The  use  of  facility  instrumentation  to  duplicate  the  control  sensors  is  strongly 
recommended  during  the  ground  tests.  The  accurate  facility  steady-state  instrumentation 
is  needed  to  provide  an  operational  calibration  of  the  control  sensors.  During  this 
testing  provisions  should  be  made  to  operate  the  DPCU  under  flight  environmental 
conditions. 

Except  for  steady-state  calibration  the  control  instrumentation  should  be  used  as  the 
primary  data  source.  Duplicate  instrumentation  should  be  used  only  to  identify  failed 
sensors  and  as  a backup  signal  for  post  event  analysis  for  those  control  sensors  which 
have  failed.  By  the  time  the  system  reaches  flight  test  it  is  likely  that  the  control 
sensors  will  have  been  tested  sufficiently  to  generate  confidence  that  they  are  more 
accurate  than  normal  flight  test  instrumentation.  jfl 
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7.4.2  Data  Recording  and  Processing 


As  a result  of  the  IPCS  experience  the  following  data  handling  requirements  have  been 
defined: 

1.  On-line  stripchart  display  of  DPCU  data  including  discrete  bits 
with  at  least  10  bit  resolution  on  continuous  variables. 

2.  Turnaround  of  24  hours  or  less  on  reduced  data. 

3.  Ready  availability  (within  24  hours  and  preferrably  essentially 
on  line)  of  plots  of  any  selected  variables. 

4.  Consistent  data  interface  for  all  tests. 

A system  designed  to  meet  these  requirements  is  described  in  this  section.  It  has  been 
designed  for  a relatively  small  program  In  which  testing  is  performed  sequentially  at 
a number  of  test  facilities.  This  design  may  not  meet  the  needs  of  all  programs,  but 
the  basic  data  processing  requirements  still  exist  regardless  of  program  size. 

The  data  handling  scheme,  illustrated  in  Figure  7.4-1,  was  designed  starting  with  the 
flight  test  requirements.  For  flight  test  it  is  necessary  to  have  on-board  data 
recording  as  well  as  telemetering  to  a ground  station.  At  the  ground  station  the  data 
will  be  recorded  again  as  a backup  for  the  flight  recording  and  displayed  for  on-line 
analysis.  In  flight  the  DPCU  data  would  be  converted  from  parallel  to  serial  data, 
recorded,  and  telemetered  to  the  ground.  For  ground  testing  on  the  airplane  the  same 
data  handling  would  be  used  except  the  telemeter  link  would  be  replaced  with  a cable. 

In  the  ground  test  facilities  the  on  board  recording  and  transmitting  would  be 
el iminated. 

The  construction  of  two  identical  data  recording  packages  would  serve  two  purposes: 
spare  components  would  be  available  during  the  flight  test  program  and  one  unit  could 
be  installed  along  with  the  data  processing  hardware  in  a mobile  data  processing  van. 

The  van  could  then  be  used  for  data  processing  during  all  the  ground  tests  and  serve 
as  a ground  station  during  the  flight  tests.  In  this  way  the  sometimes  difficult  job 
of  interfacing  between  the  DPCU  and  test  facility  data  recording  systems  can  be 
eliminated  and  the  development  of  data  processing  software  could  be  done  once  for  the 
test  program  rather  than  done  over  again  at  each  facility.  The  van  capability 
described  in  the  following  paragraphs  would  provide  good  on-line  display  with  a 
dedicated  facility  for  all  of  the  final  data  processing,  eliminating  the  need  for  off- 
line processing  by  either  the  facility  or  the  contractors.  This  bypasses  turnaround 
problems  frequently  experienced  at  test  facilities.  Facility  instrumentation  used  in 
addition  to  the  DPCU  data  should  be  recorded  on  normal  facility  systems  using  a 
common  time  code  for  correlation. 

The  data  recording  package.  Figure  7.4-2,  consists  of  a 14  track  tape  recorder,  a time 
code  generator,  and  a converter  to  transform  the  data  from  the  DPCU  from  a parallel  bit 
stream  on  separate  wires  to  a single  channel  of  serial  bit  PCM  data.  A switching  system 
will  allow  the  use  of  the  package  in  a record-only  mode  taking  the  converted  data 
from  the  onboard  package  during  testing  with  the  airplane.  The  extra  channels  of  the 
tape  recorder  will  be  used  to  direct  record  analog  data  available  from  the  DPCU. 

The  data  processing  serves  two  purposes:  on-line  and  quick  turnaround  of  data  for 

troubleshooting  and  test  planning,  and  data  reduction  for  longer  term  analysis  and 
reporting.  The  package  proposed  for  the  data  van.  Figure  7.4-3,  provides  both  of 
these  functions.  The  on-line  display  consists  of  four  8 channel  stripchart  recorders 
which  can  take  inputs  from  either  the  DPCU  analog  data  or  the  PCM  data  processed  by  a 
decom  unit  and  digital-to-analog  converters.  The  PCM  data  are  also  transmitted  to 
the  mini-computer  for  storage  on  disk  or  tape  and  digital  processing.  Data  from  the 
computer  can  be  selected  either  for  printouts  or  for  plotting  on  a very  rapid  turn- 
around basis  for  system  troubleshooting.  During  off-hours  when  testing  is  not  underway 
the  computer  can  be  used  to  print  large  volumes  of  data  and  write  magnetic  tapes  for 
production  of  microfilm,  if  desired,  for  long  term  data  storage.  The  plotting  hard 
copy  capability  will  satisfy  the  reporting  requirements  for  plots.  Data  availability 
will  permit  visual  comparison  of  events  occurring  at  different  times  during  the  test. 
Thus  of  all  the  data  processing,  only  the  routine  printing  of  microfilm  must  be  done  by 
equipment  other  than  that  which  is  contained  in  the  van  on-site.  A similar  system 
designed  around  a PDP11  was  used  at  Boeing  during  the  IPCS  program  for  generating  data 
plots.  Figure  7.4-4  is  an  example  of  such  a plot.  Unfortunately  the  equipment  was  not 
dedicated  to  IPCS  and  thus  was  not  available  at  the  test  sites. 


105 
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GROUND  TEST  WITH  AIRPLANE 


GROUND  TEST  FACILITY 


Figure  7.4-1  Data  Handling  Scheme 


Figure  7.4-2  On-Board  Data  Recording 
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The  data  van  would  contain  the  following  items: 


1.  Data  recording  package 

2.  Data  processing  package 

3.  DPCU  test  set  and 

4.  DPCU  related  simulation  and  program  compilation  hardware 

In  this  way  it  would  serve  as  the  long  term  data  Drocessing  facility;  DPCU  control 
room  using  the  stripchart  recorders,  test  set,  and  quick  data  turnaround;  and  a 
software  development  area  using  the  simulation  and  program  compilation  hardware 
which  could  share  items  such  as  the  line  printer  and  card  reader  with  the  mini-computer. 
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